Closed
Description
Configuration Profiles/Versions
- 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 intsconfig.json
support arrays seems like a reasonable workaround. - Seems like this dovetails into deprecations and default changes.
Flag Deprecations
- Do we ever believe we can remove flags?
- Question: do we always error on unknown flags?
- Requires transitions from:
- Deprecated (warning)
- Errored-on specially, but no-op behavior.
- Errored-on as unexpected(?)
- Requires transitions from:
- Question: do we always error on unknown flags?
- 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.
- Acts as if
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, useoutFile
instead.keyofStringsOnly
- rumored that we wanted this to be a temporary flag. People needed to writestring & ...
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
target
s of ES3? - Could just say
target
is always required?
- Syntax might not work in
- What's it even have?
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?
- Maybe
- What about making TypeScript just do the right type-checking out of the box?
noImplicitAny
andstrictNullChecks
really should be on.
types
array?- Ideally should be
[]
. - No way for a user to get the old 4.9 behavior.
- Ideally should be
- What are we going for? Defaults always work right? Most correct
tsconfig.json
s are always relatively short?