René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Design Meeting Notes, 6/11/2024","articleBody":"# Syntactic Form for Preserving Computed Property Names\r\n\r\nhttps://github.com/microsoft/TypeScript/pull/58829\r\n\r\n* When you have `isolatedDeclarations`, you can't use computed property names in object literals and classes.\r\n    * They transform into different forms depending on the type (symbol, string types, etc.).\r\n* We basically said they're not supported under `isolatedDeclarations`.\r\n* This proposal is to support computed property names under `isolatedDeclarations` by introducing a new syntactic form.\r\n\r\n  ```ts\r\n  export const obj = {\r\n    [someValue satisfies keyof]: 123,\r\n  };\r\n  ```\r\n* Idea is this should be transformed into the following declaration file:\r\n\r\n  ```ts\r\n  export declare const obj: {\r\n      [someValue]: number;\r\n  };\r\n  ```\r\n* Under this, `someValue` must be a singleton/unit type.\r\n* What is the specific use-case here?\r\n    * Need to preserve the exact syntax input by the user - codebases with computed properties can't use `isolatedDeclarations`.\r\n* Do we really need new syntax for ID?\r\n* Why can't we just error in cases when an \"optimistic inference\" would not succeed?\r\n    * We didn't feel okay doing optimistic inference in general.\r\n* Why can't we just emit the expression as-is always?\r\n    * A computed property resolves differently depending on ambient vs. non-ambient contexts.\r\n    * Also, we'd need to now preserve the declaration of more non-exported values.\r\n        * We do that for `typeof` anyhow.\r\n    * In general, it's a breaking change.\r\n\r\n# Only Look up `type` from `package.json` when in `node_modules` (and in `node16`)\r\n\r\nhttps://github.com/microsoft/TypeScript/pull/58825\r\n\r\n* Got feedback on a feature that we added in 5.5 where we look up `package.json`.\r\n* Two issues reported.\r\n    * First: dual-publish. CJS and ESM.\r\n    * Second: script file that really wasn't meant to be driven by a `package.json` farther up the spine.\r\n    * Third: doing all this work causes a lot of file-watching.\r\n* A few options:\r\n    * Revert all of this.\r\n    * Only expand the behavior to modules inside of `node_modules`.\r\n    * Roll with it.\r\n* How does it work with monorepos with symlinked dependencies in `node_modules`?\r\n    * Seems like it plays \"correctly\" - we always go through `realpath` and figure out where the actual file is.\r\n\r\n# Analyze Control Flow Effects of Callbacks\r\n\r\nhttps://github.com/microsoft/TypeScript/pull/58729\r\n\r\n* Considered a strictness flag - but feels like maybe this should be the default.\r\n* Issues around the `Deferred` helper conflicting with libraries using this type.\r\n    * Using a type helper probably communicates the wrong thing as ewll.\r\n* What's the work-around for when the caller doesn't mark something as `deferred`?\r\n    * Define a helper function called `deferred` that just takes and returns the function.\r\n\r\n      ```ts\r\n      function deferred\u003cT extends (...args: any[]) =\u003e any\u003e(deferred fn: T): T {\r\n          return fn;\r\n      }\r\n      ```\r\n* All the examples of new breaks running over GitHub are kind of expected - places where `deferred` will need to be added.\r\n    * But which of these are wins?\r\n    * Maybe the `tinacms` examples.\r\n    * And Pyright has a missing non-null assertion.\r\n* What happens if you mark a parameter as `deferred` and it's not deferrable?\r\n    * We could error on that.\r\n* Some have asked about why we only do this for function expressions and not declarations (or constants initialized to function expressions).\r\n    * Easier to explain, visually shows up.\r\n    * And it would be a *whole* lot more analysis.\r\n    * And then issues around circularities due to resolving each name.\r\n* Does `deferred` affect assignability?\r\n    * Right now we don't do anything special.\r\n    * Currently it's an intrinsic type that doesn't affect assignability.\r\n","author":{"url":"https://github.com/DanielRosenwasser","@type":"Person","name":"DanielRosenwasser"},"datePublished":"2024-06-18T23:13:40.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/58918/TypeScript/issues/58918"}