Design Meeting Notes, 2/16/2024

[DanielRosenwasser]

Other ways to extend contents of tsconfig.json files

#56436

• Want people to be able to merge properties from other tsconfig.jsons.
  • Today, you can only override them, sometimes don't inherit them.
  • Could look like an array of properties you want merged, or an object that can be merged.
  • Could also look like a field called extends or merge which implies merging behavior for every listed property, and can add contents as well.
• 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
  • 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
  • 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.
  • Another option is to use an interpolation string like "${workspaceDir}".
    • Some support around this idea because it's similar to tsconfig.json.
• Having a weird time understanding use-cases with references due to transitive dependencies?
  • Something with dual builds.
• Agree with solving the problem space, but trying to find good ergnomics.
• Are there order-dependency risks?
  • Path mapping, type roots, stuff like that.
• Could have imagined if we did it all over again today, we'd do compilerOptions being overrides, and mergedCompilerOptions.
• If we did it all over again, would we have just picked merge as the default strategy?
  • Certainly for paths, typeRoots, maybe lib.
  • In a sense we do merge, but it's just not deep.
• So should we try to change the default of how tsconfig.json inheritance operates?
  • Fix everything in TypeScript 6.0
  • That might be a way bigger break than you realize!
• VS Code does automatic merging and interpolated variables.
  • No way to override! Only merge!
• If we did interpolated variables.
  • Path of configuration file
    • configLocation
    • configFolder
    • configDirectory
    • projectLocation
    • projectFolder
    • projectDirectory
  • fileName - could model a project build for different targets like tsconfig.cjs.json and tsconfig.esm.json
    • "Please let's not talk about project references here."
      • Editor's note: :(
• Consensus around introducing an variable name like ${configDirectory} once we know what the actual name is.

Instantiate earlier inferred constraints in conditional type

#57362

• Bug a long time ago - type parameters would leak when they referred to themselves in a conditional type extends clause.
• Fixed the issue for a subset of types that were considered directly generic - but not instantiations of object types with type parameters.
• New fix includes the infer type parameters in the new inference context.
• ✅

Avoid creating rest elements with errorType when any is spread

#57116

• 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[].
  • 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.
• The PR seems right, maybe lacking a test for spreading in other kinds of any types like the error type itself.
• ✅