Don't allow a `Record` keyed by a template literal type to be assigned to a type without a compatible index signature

[tylerc]

🔍 Search Terms

record index indexed type template literal type assignable assignability

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Types like Record<`id_${string}`, { foo: 'bar' }> are common in our apps, but it is surprisingly easy to accidentally assign an object with an incompatible type. It would help catch errors (especially during refactoring) if a compatible index signature type was required for assignment.

📃 Motivating Example

During a recent refactoring, a previously infallible function was changed to return a list of warnings along with its result. One of the use sites was missed during the refactoring, resulting in a bug that it feels like TypeScript could've caught:

type Mapping = Record<`id_${string}`, { foo: 'bar' }>;

// Previously, this just returned a Mapping directly
function computeMappingAndWarnings(): {
  mapping: Mapping,
  warnings: string[]
} {
  return {
    mapping: {},
    warnings: []
  };
}

const result: Mapping = computeMappingAndWarnings(); // 🐛 Expected error here, meant to assign .mapping field.

Playground Link

💻 Use Cases

1. What do you want to use this for? - Safer use of Record types when keyed by template literal types.
2. What shortcomings exist with current approaches? - We could use a Map instead, but Maps don't survive the roundtrip from JSON and back, and so can be harder to use when crossing the network boundary.
3. What workarounds are you using in the meantime? - For now we're converting to Maps where we can, and are viewing existing Records with suspicion.

[RyanCavanaugh]

This is the intended behavior of index signatures - they're a constraint on what types the values matching the key are allowed to be, not a constraint on which keys are allowed to be present. To solve this code sample, you'd want exact types to say that only keys with id_{string} are allowed; see #12936

[tylerc]

To solve this code sample, you'd want exact types to say that only keys with id_{string} are allowed

Ah, thank you! Exact types do seem to be what we would want here.

Seems like that's a whole bag of worms, though, so I won't get my hopes up. I wonder if there's a lesser version of exact types that could be applied purely to index signatures. If time permits I'll do some research and prototyping and will report back.

[typescript-bot]

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.