Skip to content

Design Meeting Notes, 10/26/2022 #51323

Closed
@DanielRosenwasser

Description

@DanielRosenwasser

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.
  • 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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions