Repository: TypeScript
Issue: Expanded function return type for certain mapped types in compiled output causes index access error
Labels: Bug,Fix Available,Rescheduled

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

index access function return compiled .d.ts expansion

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior.
  This should have the same code as the code snippet below, and use whichever settings are relevant to your report.

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=5.2.0-beta#code/C4TwDgpgBBBuCGAbArvYEA8wB8UC8UA3lANoDWUAlgHZRkQgD2AZlMALoBcb57UAvlABkUZNTLVGAd2oAoWRAAeYRgCdgbcNAjVgqkAHlmGRrgJwkqdBllQ7RUhRp0GLKI3YBaAPzdyAGndeYSgACkJBAB8oamRERABKPn4SRhhFdGoAEwBnKFUIeCzGakQQUXFJGRJ2W3t67xcmVjSRWIBbACMIVTr6u256Zvda7HklFXVNSBhdVUoIHKMTdMzc906AKwgAYxx8GAQUNEwdPUNjUxqxhWU1DR2SnI0z+cWjA5WlNbzGLd2cKFGNxGAl8GN6gZ-nsAHSvBY5IFg+B5eHvS43IA)

### 💻 Code

<!-- Please post the relevant code sample here as well. This code and the Playground code should be the same, do not use separate examples -->
```ts
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>
```

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->

TS source has no errors, compiled .d.ts has errors

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->

Either TS source should have errors, or .d.ts should not have errors

### Addendum

This resulted in [a blocking issue](https://github.com/arktypeio/arktype/issues/823#issuecomment-1638192014) for an ArkType user who wasn't able to enable `skipLibCheck` in their CI environment.

Though the repro conditions are somewhat specific, issues like this can cause big problems for library authors, as I don't think it is commonplace to check build output for errors after TSC is successful.

Although in this specific case a faulty return type expansion seems to be at fault, in general I'd love if the default on `skipLibCheck` could be revisited. As I understand based on a conversation with @Andarist, individual TSConfig settings like `exactOptionalPropertyTypes` can affect whether some dependency blocks your build if `skipLibChecks` is not manually enabled.

Perf considerations aside, while I understand how it could be useful to know if the types of one of your dependencies is doing something unexpected, there's no feasible way for libraries to avoid these types of problems without checking their types under multiple combinations of TSConfig settings. Even if in a case like this the root of the problem isn't config-specific, very often it's something like an index access in a generic that doesn't affect the computed type at all and could have been safely ignored by the end-user. The resulting issue caused for both the user and maintainer can be difficult to track down and address, whereas I'd question how often the average TS user with `skipLibCheck` defaulted is being alerted to useful problems (which I guess they're supposed to pass on to maintainers?).

The only path I can see to this being a reliable source of errors is if TS could load multiple TSConfigs simultaneously and apply per-directory settings so that dependencies had control over the rules that applied to their own types, but I assume that would be a massive undertaking. Barring that or a default change, maybe some gold standard for "check your types against this config, if they work here then they should work with any config" could be adopted by libraries hoping to avoid this (not sure whether this possible or some settings have mutually exclusive results).

EDIT: Just found https://github.com/microsoft/TypeScript/pull/49886, so maybe these is hope for the required subset to be included as part of the compilation if the performance issues can be mitigated. Though I'd still question whether `skipLibChecks` would be a net positive, I'd feel much better about it if I could include our config options in our .d.ts output👍