René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Design Meeting Notes, 2/16/2024","articleBody":"# Other ways to extend contents of `tsconfig.json` files\r\n\r\nhttps://github.com/microsoft/TypeScript/issues/56436\r\n\r\n* Want people to be able to merge properties from other `tsconfig.json`s.\r\n    * Today, you can only override them, sometimes don't inherit them.\r\n    * Could look like an array of properties you want merged, or an object that can be merged.\r\n    * Could also look like a field called `extends` or `merge` which implies merging behavior for every listed property, and can add contents as well.\r\n* It's not just merging - also want to be able to do a \"raw\" copy so that things become relative to the current `tsconfig.json`\r\n    * e.g. inherit `outDir` in a way where things become relative to the current `tsconfig.json`, rather than being normalized and copied from the original `tsconfig.json`\r\n    * One idea is to have a `raw` field (similar to a `merge` field) that lists the properties you want to do a raw copy of.\r\n    * Another option is to use an interpolation string like `\"${workspaceDir}\"`.\r\n        * Some support around this idea because it's similar to `tsconfig.json`.\r\n* Having a weird time understanding use-cases with `references` due to transitive dependencies?\r\n    * Something with dual builds.\r\n* Agree with solving the problem space, but trying to find good ergnomics.\r\n* Are there order-dependency risks?\r\n    * Path mapping, type roots, stuff like that.\r\n* Could have imagined if we did it all over again today, we'd do `compilerOptions` being overrides, and `mergedCompilerOptions`.\r\n* If we did it all over again, would we have just picked merge as the default strategy?\r\n    * Certainly for `paths`, `typeRoots`, maybe `lib`.\r\n    * In a sense we do merge, but it's just not deep.\r\n* So should we try to change the default of how `tsconfig.json` inheritance operates?\r\n    * Fix everything in TypeScript 6.0\r\n    * That might be a way bigger break than you realize!\r\n* VS Code does automatic merging and interpolated variables.\r\n    * No way to override! Only merge!\r\n* If we did interpolated variables.\r\n    * Path of configuration file\r\n        * `configLocation`\r\n        * `configFolder`\r\n        * `configDirectory`\r\n        * `projectLocation`\r\n        * `projectFolder`\r\n        * `projectDirectory`\r\n    * `fileName` - could model a project build for different targets like `tsconfig.cjs.json` and `tsconfig.esm.json`\r\n        * \"Please let's not talk about project references here.\"\r\n            * *Editor's note: :(*\r\n* Consensus around introducing an variable name like `${configDirectory}` once we know what the actual name is.\r\n\r\n# Instantiate earlier inferred constraints in conditional type\r\n\r\nhttps://github.com/microsoft/TypeScript/pull/57362\r\n\r\n* Bug a long time ago - type parameters would leak when they referred to themselves in a conditional type extends clause.\r\n* Fixed the issue for a subset of types that were considered directly generic - but not instantiations of object types with type parameters.\r\n* New fix includes the `infer` type parameters in the new inference context.\r\n* ✅\r\n\r\n# Avoid creating rest elements with `errorType` when `any` is spread\r\n\r\nhttps://github.com/microsoft/TypeScript/pull/57116\r\n\r\n* Made a change where if you spread in something of type `any` into the end of an array and then try to destructure it, you end up with `unknown[]`.\r\n    * Why? When you spread `any`, you end up with `errorType` as the rest element type. But then you end up with `unknown[]` when you slice the end off.\r\n* The PR seems right, maybe lacking a test for spreading in other kinds of `any` types like the error type itself.\r\n* ✅","author":{"url":"https://github.com/DanielRosenwasser","@type":"Person","name":"DanielRosenwasser"},"datePublished":"2024-02-16T19:56:14.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/57425/TypeScript/issues/57425"}