Design Meeting Notes, 9/30/2022

[DanielRosenwasser]

Configuration Profiles

#50997

• Unconstrained type parameter incompatibility with {} felt like a tough choice.

  • Every codebase should start out with it, but we didn't want to add a flag.

• Tentative stuff

  {
      "compilerOptions": {
          "profile": "argon" // option name and option value are up for debate
      }
  }

  • Idea is that this locks in a set of defaults for a specific profile
    • strictness flags
    • target
    • etc.

• Why not extend tsconfig?

  // 4.9-tsconfig.json
  {
      "compilerOptions": {
          "noImplicitAny": false,
          "strict": false
      }
  }
  
  {
      "extends": "4.9-tsconfig.json",
      "compilerOptions": {
          "strict": true
      }
  }
  // Observably different if we change defaults in 5.0, 6.0, or whatever

  • But...are we going to change the defaults in future versions?
  • This would allow us to do that - because eventually people would be using profiles.
    • Ideally? But plenty of people start projects without tsc --init and would start without a profile. Those people are arguably the people who have the least context/awareness around a change to defaults.
  • Today, an extends field aggregates all the properties and then calculates the effective options.
    • You sort of want the opposite here.
    • Profiles would do the opposite here.
      • Seems strange that we would need others to understand all the nuances between versions.
      • Also, this is partially why a lot of tools moved to JS config instead of JSON.
        • Yeah, but asking someone to know the nuances is a much smaller ask (even if it's a big ask to begin with) than needing a JS engine and a host. Can't expect eslint, swc, etc. to ship a JS engine to interpret options.
  • How is this different from shipping a config?

• How does extends and the profile interact?

• Seems specific to "computed" options.

  • Are there any apart from --strict?
  • Yes, target/module, target/useDefineForClassFields, module/moduleResolution, ...

• Why don't we want the values to be version numbers?

  • In C#, there's a language mode that you can set which will actually turn on/off old behaviors. Don't want to give the impression that we're going to preserve bug behavior.
  • Unclear if that's what we're communicating - but really is unclear if profiles are defaults for best practice, or if they snapshot different tsconfig defaults across major versions.
    • It can be both!
      • Really? Seems unclear. Also, shifting defaults seems like a total pain for tools.
      • Considering this a defaults is interesting.

• This sort of thing is useful for having tsconfigs work in old versions of TS, since older options aren't recognized by the compiler.

• What exactly is the user scenario?

  • Upgrading stable? Moving forward well? Allowing design space for the compiler?
  • Another layer of subtlety on top of --strict and other computed flags.

• How does --showConfig work with this? Do you show the config as interpreted by the older version? By the current version?

• If you don't want to be broken, --strict false is the right approach.

• Maybe what we actually want is strictness profiles.

  • Versioned --strict was a bit more paletable for some of this.
  • Most tools don't have to think about it unless you're actually building a TypeScript type-checker. Way fewer of those than compilers!
    • --strict false = --strict 0
    • --strict true = --strict latest

• But not every checking flag is under --strict

  • e.g. --keyofStringsOnly
  • You also can't really remove --strict 2 or whatever.

• What are the problem statements?

  • New behaviors that are too breaky to add under --strict.
  • tsc --init should have a simpler base.
  • TypeScript's defaults are no longer "good" for a new project (sort of related to the above).

• Constraints?

  • Obviously new complexity and cognitive load. Want to limit that.
  • Interoperability with other build tooling (e.g. esbuild, Babel, etc.)