Bug报告

🔎 搜索词

index access function return compiled .d.ts expansion

🕗 版本与回归信息

• 在我尝试的每个版本中，都是这种行为

⏯ Playground链接

带有相关代码的Playground链接

💻 代码

type evaluate<t> = { [k in keyof t]: t[k] } & unknown

export type entryOf<o> = evaluate<
    { [k in keyof o]-?: [k, o[k] & ({} | null)] }[o extends readonly unknown[]
        ? keyof o & number
        : keyof o]
>

export type entriesOf<o extends object> = evaluate<entryOf<o>[]>

export const entriesOf = <o extends object>(o: o) =>
    Object.entries(o) as entriesOf<o>

🙁 实际行为

TS源没有错误，但编译后的.d.ts有错误

🙂 预期行为

要么TS源应该有错误，要么.d.ts不应该有错误

附录

这导致了一个ArkType用户无法在他们的CI环境中启用skipLibCheck的问题。虽然重现条件有些特定，但类似这样的问题可能会给库作者带来很大的麻烦，因为我认为在TSC成功后检查构建输出中的错误并不常见。
尽管在这个特定的情况下，错误的返回类型扩展似乎是问题的根源，但一般来说，我希望skipLibCheck的默认值能够得到重新审视。根据与@Andarist的对话，如果skipLibChecks没有手动启用，那么像exactOptionalPropertyTypes这样的单个TSConfig设置可能会影响依赖项是否阻塞构建。
除了性能考虑之外，虽然我知道了解依赖项类型是否执行意外操作可能很有用，但没有可行的方法让库在不检查多种TSConfig设置组合下的类型的情况下避免这类问题。即使在这种情况下问题不是特定于配置的根源，通常也类似于通用类型中不影响计算类型的索引访问，这些类型本可以被最终用户安全地忽略。由此产生的用户和维护者之间的问题可能很难追踪和解决，而我想知道平均TS用户使用skipLibCheck默认值时有多少次会被提醒有用的问题(他们应该把这些问题转交给维护者吗？)。
我认为唯一能使这个错误成为可靠来源的方法是，如果TS能够同时加载多个TSConfig并对每个目录应用设置，以便依赖项可以控制应用于其自己的类型的规则，但我假设这将是一项巨大的工程。除非改变这个或默认值，也许一些希望避免这个问题的库可以采用“检查你的类型是否符合此配置，如果它们在这里工作，那么它们应该适用于任何配置”的标准(不确定这是否可能或者某些设置有互斥的结果)。
编辑：刚刚找到了#49886,所以也许如果性能问题得到缓解，可以将所需的子集作为编译的一部分包含进来。尽管我仍然质疑skipLibChecks是否会带来正面影响，但如果能将我们的配置选项包含在我们.d.ts输出中，我会感觉好多了