Design Meeting Notes, 10/26/2022

[DanielRosenwasser]

Configuration Profiles/Versions

https://github.com/microsoft/TypeScript/issues/50997

• Some option that tells TypeScript "use some set of well-known best practice options."
• Somewhat opaque, needs more documentation.
• Adds more complexity.
• Having the extends field in tsconfig.json support arrays seems like a reasonable workaround.
  • https://github.com/microsoft/TypeScript/issues/29118
  • https://github.com/microsoft/TypeScript/pull/50403
  • 5.0-bound.
• Seems like this dovetails into deprecations and default changes.

Flag Deprecations

https://github.com/microsoft/TypeScript/issues/51000

• Do we ever believe we can remove flags?
  • Question: do we always error on unknown flags?
    • Requires transitions from:
      1. Deprecated (warning)
      2. Errored-on specially, but no-op behavior.
      3. Errored-on as unexpected(?)
• Deprecation and removal provides us a back-out plan.
• Can we do this with some of our flags?
  • "I know it when I see it"
• We don't follow semver, but a major version is a good time to start deprecating.
• Feels like we should have good explanations, work-arounds, maybe quick fixes.
• Must have a "shhh I don't mind using deprecated flags".
• Is deprecation worthwhile, or will people turn it off?
• We do want to give people leeway and a heads-up.
• Obvious flags for deprecation
  • charset - doesn't do anything today?
  • noImplicitUseStrict
    • Acts as if "use strict" is at the top of a file.
  • noStrictGenericChecks
    • We used to erase generics in signatures when relating them. 2.4 changes this, but dependencies would have issues and we needed an opt-out flag.
  • out - various issues, use outFile instead.
  • keyofStringsOnly - rumored that we wanted this to be a temporary flag. People needed to write string & ... instead of ... in some cases, but was confusing.
  • suppressExcessPropertyErrors - type system has other capabilities for enabling these.
  • suppressImplicitAnyIndexErrors - literal types probably help guard against these.
• Questionable
  • noFallthroughCasesInSwitch - feels linty - not our domain
    • The other ones seem like misfeatures/back-compat.
• Arguable
  • target: es3
    • What's it even have?
      • Errors for using getters/setters, property name downleveling for reserved words, removal of trailing commas.
    • What about the default for target?
      • Syntax might not work in target environment.
      • We would like to move the target to a newer version. But do we deprecate ES3 first, or change the default to ES5 and deprecate explicit targets of ES3?
      • Could just say target is always required?
  • module: umd, system, amd
    • Seems like these all have usage.
    • Snooze, maybe talk to some teams to better understand usage.
• What's the upgrade process?
  • Maybe --upgrade on the command-line?
• What about making TypeScript just do the right type-checking out of the box?
  • noImplicitAny and strictNullChecks really should be on.
• types array?
  • Ideally should be [].
  • No way for a user to get the old 4.9 behavior.
• What are we going for? Defaults always work right? Most correct tsconfig.jsons are always relatively short?

[Jack-Works]

do you consider shipping ES6 syntax starting from 5.0?

[DanielRosenwasser]

Yes, we're considering 5.0 just shipping eS2015 syntax (though I believe CJS will be our module format - @jakebailey for validation).

[jakebailey]

The notes seem to be wrong; we're doing ES2018 (which is Node 10's level).

The outputs are still UMD-esque. ESM later, that's just more difficult.

[jakebailey]

Er, I meant the notes on #51310; I didn't read which design meeting notes this was.

What syntax we ship in our package doesn't affect which syntaxes the compiler supports, of course, which is what this issue was referring to.

[DanielRosenwasser]

(same, I misread)