[isolatedDeclarations] Add a syntactic form of computed property name which is always emitted as a computed property name

🔍 Search Terms

isolatedDeclarations transpileModule computed property name

✅ 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

Background

Computed property names under isolatedDeclarations are very limited right now. Today, you can write {[Symbol.iterator]: ...} and that's about it. This restriction is in place because for an arbitrary {[expression]: ...} we don't know if the type should be {[expression]: something}, {[expression: string]: something} or even {} (or a future {f1: something} | {f2: something}). Computed property names in types today have to exactly be a single late bindable name - nothing more, nothing less - meanwhile computed property names in object expressions (and class declarations) are much more flexible in what we allow.

Thus far, this has worked pretty well for TS users, since we basically pre-solve and cache whatever the expression computed name resolves to into our declaration files. Unfortunately, for isolatedDeclarations users, this poses a problem, since the expression in the computed property name may be from or rely on type information from another file. In such a case, it's impossible to know how to emit the type for the expression. You could optimistically emit {[expression]: something}, but if expression ends up evaluating to string or any in a whole-program context, the declaration file will produce an error and incorrect type information.

Proposal

What we could use in such a scenario is a syntactic opt-in to guaranteeing the preservation of a computed property name in the calculated type for an expression. A form of computed property name that, when you see it, always ensures a computed property name appears in the output, and issues checker errors if the types when checked cannot produce a valid computed property name in a declaration file.

I propose we reuse some existing syntax with a bit of a new meaning to accomplish this - a satisfies keyof postfix assertion, only valid in computed property name positions, and only on dotted entity name expressions. This would mean you could write

export const a = {
  [something satisfies keyof]: () => {}
}

and we would always emit

export const a: {
  [something]: () => void;
};

and issue an error on something satisfies keyof if something isn't exactly a single unique symbol, string literal, or number literal type (as is valid in the type position computed property name).

Compatibility

Only isolatedDeclarations-concerned authors really need to think about this feature - it's erased from declaration files, since they already check this constraint, so library consumers will never see it. People not using isolatedDeclarations will never be driven to use it, since they will always be able to produce a declaration type without an assertion. This is pretty easy to integrate into the isolatedDeclarations quickfixer. This doesn't conflict with existing satisfies keyof T assertions, since they require a type argument for keyof. There is also the possibility of allowing satisfies keyof in other locations and on arbitrary expression kinds in the future to check the same invariant - that the expression is exactly a single literal key type - if we think such a check has use in broader contexts than just computed property names.

Addenda: Making error cases better

Once we have {[expression satsifies keyof]: ...} in place, we know that that computed property name should always produce exactly one object key, even if expression doesn't produce a valid key type (and thus an error). In such a scenario, it could be beneficial to override the type of expression with a property key unique to the expression symbol, and then fallback to using such a symbol whenever later obj[expression] lookups fail. In this way, we can preserve as much user intent as possible, without rapidly reverting to an unchecked any state. This is neat (I have a working prototype), especially in the context of single-file checking modes like what our language service does when loading the full program in the background, but isn't really necessary for the feature. The open questions I have for this are just

1. Is it worth supporting this scenario with a special case? and
2. Should the keyof result of a type containing one of the fallback property keys be adjusted to be string | number | symbol? Should the fallback error property just be filtered from keyof entirely?

Empieza por seguir el manejo de isolatedDeclarations para los nombres de propiedades calculados y las reglas del checker para las claves calculadas de los declaration files. Revisa cómo el isolatedDeclarations quickfixer podría integrar la sintaxis propuesta. Se considera terminado cuando la sintaxis, la validación, el declaration emit y los casos de error relevantes están especificados y cubiertos por pruebas.