René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[isolatedDeclarations] Add a syntactic form of computed property name which is always emitted as a computed property name","articleBody":"### 🔍 Search Terms\r\n\r\nisolatedDeclarations transpileModule computed property name\r\n\r\n### ✅ Viability Checklist\r\n\r\n- [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code\r\n- [X] This wouldn't change the runtime behavior of existing JavaScript code\r\n- [X] This could be implemented without emitting different JS based on the types of the expressions\r\n- [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)\r\n- [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types\r\n- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals\r\n\r\n### ⭐ Suggestion\r\n\r\n# Background\r\n\r\nComputed 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.\r\n\r\nThus 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.\r\n\r\n# Proposal\r\nWhat 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.\r\n\r\nI 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\r\n```ts\r\nexport const a = {\r\n  [something satisfies keyof]: () =\u003e {}\r\n}\r\n```\r\nand we would always emit\r\n```ts\r\nexport const a: {\r\n  [something]: () =\u003e void;\r\n};\r\n```\r\nand 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).\r\n\r\n# Compatibility\r\n\r\nOnly `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.\r\n\r\n# Addenda: Making error cases better\r\n\r\nOnce 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\r\n1. Is it worth supporting this scenario with a special case? and\r\n2. 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?\r\n","author":{"url":"https://github.com/weswigham","@type":"Person","name":"weswigham"},"datePublished":"2024-06-07T16:17:56.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/58800/TypeScript/issues/58800"}