Configuration Profiles/Versions

#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.
  • tsconfig.extends as array #29118
  • Fix(29118): tsconfig.extends as array #50403
  • 5.0-bound.
• Seems like this dovetails into deprecations and default changes.

Flag Deprecations

#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?