GeezerVison is showing github.com — Flag Deprecation Plan · Issue #51000 · microsoft/TypeScript
Flag Deprecation Plan #51000DescriptionTypeScript Flag Deprecation Plan
(This is a proposal, but written in terms of a blog post for clarity)
As we think about the long-term future of TypeScript and its place in the JavaScript ecosystem, it's clear that many things TypeScript 0.8 users in 2012 needed aren't things that TypeScript users in 2024 are going to need. For example, in 2012, Internet Explorer 8 (which only supports ECMAScript 3) had enough marketshare to warrant serious compatibility concern. Today, thankfully, it doesn't.
While we still consider long-term language stability to be an absolutely paramount concern, having a well-defined deprecation policy in place also makes it easier for us to be slightly less risk-averse when adding new features to the language.
To that end, starting with TypeScript 5.0, we will begin the process of removing certain flags, features, and/or behaviors which we think the language or ecosystem have largely evolved past the need for.
Schedule
The deprecation schedule is based on our existing version += 0.1 versioning cadence, aligned with ones-place-incrementing versions for clarity.
| Release / Phase |
Description |
| TypeScript 5.0 - Phase 1 |
❔ Deprecation warnings introduced |
| TypeScript 5.5 - Phase 2 |
⚠ Flags start doing nothing |
| TypeScript 6.0 - Phase 3 |
❌ Flags removed entirely |
The cycle repeats again with TypeScript 6.0 also introducing whatever new deprecation warnings deemed appropriate at that time.
Phase 1: ❔ Deprecation Warnings
In phase 1 (e.g. TypeScript 5.0), using a deprecated flags will produce a commandline error:
TS9998: Flag 'keyofStringsOnly' is deprecated and will stop functioning in TypeScript 5.5. Specify 'ignoreDeprecations: "5.0"' to silence this error
As hinted to in the error, you can supply a new flag value to silence this error:
ignoreDeprecations: "5.0"
All other behavior is unchanged.
This gives people an immediate warning of impending deprecation, but won't block them from upgrading to TypeScript 5.0.
Phase 2: ⚠ Flags Start Doing Nothing
In phase 2 (e.g. TypeScript 5.5), deprecated flags can still be specified in tsconfig / commandline settings, but no longer have any effect. This allows users to have tsconfig.json files that work on both sides of the deprecation cycle (as you might have in a monorepo with a "shared" tsconfig settings file).
Phase 3: ❌ Flags Removed
In phase 3 (e.g. TypeScript 6.0), it is an error to specify a deprecated flag.
At this point, it also becomes illegal to have ignoreDeprecations: "5.0, since this setting doesn't do anything (it's illegal to specify those flags in the first place, and they've done nothing for 5 versions).
In 6.0, the only legal value of ignoreDeprecations will then be "6.0", per its Phase 1.
5.0 Deprecation Candidates
This list is provisional; please leave comments if you are depending on these in a serious way.
Removed entirely:
charset - already deprecated since approximately the beginning of timenoImplicitUseStrict - non-strict-mode code is extremely rare in modern JSnoStrictGenericChecks - this flag is broadly a bad idea, and improvements to the type system have rendered its original use cases largely mootout - already deprecated since approximately the beginning of time (use outFile instead)keyofStringsOnly - according to a rumor, we only wanted to ship this for three releases (2.9, 3.0, 3.1) when we added this!suppressExcessPropertyErrors - improvements in not performing subtype reduction have rendered its original use cases largely mootsuppressImplicitAnyIndexErrors - the use cases here have been supplanted by better recognition of literal-typed keysnoFallthroughCasesInSwitch - style concern; use a linter if this is not allowed in your coding style
Removed possible values:
target - remove ES3 - no known extant software runs ES3 (this will be even more true in 2 years), and we don't have lib support for it anywaymodule - remove umd, system, and amd - the ecosystem is rapidly converging, and better downlevelers exist for each of these should you still need them by 2024 Reacted by Andrii Dieiev, Jake Bailey, Oleksandr Tarasiuk, James Bromwell, Andrew Branch, Elian Cordoba, Rob Palmer, Victorien Elvinger, Jack Works, Joe Percy and 66 more Reacted by Kosta Prosenikov, Jesse Pence, Tufan Al-Aqsa and lin72h Activityfatcerberus commented on Sep 29, 2022
non-strict-mode code is extremely rare in modern JS
While absolutely true, devil’s advocate argument is that there’s still a difference in JS today between a (non-module) file with a "use strict" at the top and one without—and TS is meant to be spec-compliant outside of type annotations as a design goal. RyanCavanaugh commented on Sep 29, 2022 One reason I advocate for removing noImplicitUseStrict is that no one ever can remember what it actually does, which based on reading the description I wrote up there, includes me 😬 Reacted by Nico Jansen, Josh Ghoulberg 👻, Artem Kamysh, Jesse Pence and Bosco Domingo MartinJohns commented on Sep 30, 2022 Considering the current release cycle of 3 months, I think two and a half years quite too long for this. But otherwise I'm all for deprecating stuff. 👍 Reacted by Kirill Groshkov, Shivam Dwivedi, Gabriele Tomberli, Shane (Peng Jun Hsu), Reece Carolan and Matthias Kunnen robpalme commented on Oct 1, 2022 This sounds great. Freedom to evolve is important and this plan increases it whilst decreasing tech debt (entropy).
I recommend updating column 1 of the table to switch the order and say "Phase 1 (e.g. TypeScript 5.0)". Right now it looks like you are mandating 5 minors releases between each phase whereas the description that follows indicates it is only an example duration.
3.5 years (10 releases) to complete an entire deprecation cycle seems excessive. I'd suggest 2-4 releases for the full cycle would normally be fine. Reacted by Jack Works, Kirill Groshkov, electron-space, Jason Fields, Michal Minich, John Reilly, Steven, Toni Villena, flexiworld, Francesco Fortin and 8 more RyanCavanaugh commented on Oct 27, 2022 Summarizing decisions from the meeting:
Queued for deprecation: noImplicitUseStrict , target: es3, keyofStringsOnly, suppressExcessPropertyErrors, suppressImplicitAnyIndexErrors, noStrictGenericChecks, charset, out
Still alive: All module targets (usage of these, based on GitHub queries, is higher than I anticipated). We'll investigate top repos using these targets (especially umd and systemjs) to see what their build systems are and try to evaluate their likelihood to adopt new TS versions (e.g. are these projects effectively archived?), new build system (e.g. do they seem to be wanting to move to a newer target), or whether these config settings are even active (e.g. are they actually using a different emitter?)
Also still alive, for now: noFallthroughCasesInSwitch - while we don't want to add any new lint-like rules to TS, this one is still high-value for what it does and asking folks to pick up a linter if they're happy with our limited lint-y offerings seems a bit much.
Possibly gone sooner?: I'm proposing that we just remove charset and out entirely in 5.0. Since these haven't worked anytime in recent memory, they're effectively already deprecated and any runway seems unneeded. Reacted by Jake Bailey, Andrew Branch, Victorien Elvinger, Oleksandr Tarasiuk, Michael Kim, electron-space, Michal Minich, John Reilly, Toni Villena, Tommy Troy Lin and 6 more Jack-Works commented on Nov 1, 2022
non-strict-mode code is extremely rare in modern JS
While absolutely true, devil’s advocate argument is that there’s still a difference in JS today between a (non-module) file with a "use strict" at the top and one without—and TS is meant to be spec-compliant outside of type annotations as a design goal.
So instead, add a new type check error for non-module files:
TS____: This file requires a "use strict" directive.
Reacted by Okku, flexiworld and ExE Boss Jack-Works commented on Nov 2, 2022 Add a new --legacyDecorator flag and deprecates --experimentalDecorator Reacted by Okku, Robin Van den Broeck, Abhishek Datta and whzx5byb styfle commented on Nov 2, 2022 MartinJohns commented on Nov 3, 2022 Bessonov commented on Nov 17, 2022 Just my 2 cents: If it helps ship more features/bugfixes, I would vote for removement of already deprecated flags in 5.0. Additionally, I vote for faster removement of new deprecated flags. For example, not more than one year after deprecation. Or even in 2 ts releases. Ikaer commented on Nov 29, 2022 I'm still using module "amd" with requirejs in some of my old projects :/. Is that so old school ? Reacted by remag9330 and Michael Kim coolCucumber-cat commented on Nov 16, 2023
I'm still using module "amd" with requirejs in some of my old projects :/. Is that so old school ?
Yes. We have modules now so there's no reason why you would ever need this after 2015. It's just increased complexity and dead code to support something no one uses or should use. We should deprecate CJS too, it's only used in old code, doubt anyone is compiling any new code with it. reporter123 commented on Nov 18, 2023 cjs is the only one I actually learned when I studied javascript programming a couple years back. Nodejs at that time still had a few big debug frameworks that needed it. I think even they now have stable es model support. Separate tools like Babel can make the conversion if its still needed. copilotenstar commented on Jul 22, 2024 WHY deprecate noImplicitUseStrict? Better question, why does TypeScript want to emit 'use strict' so badly? Pretty retarded if there's not going to be an option to turn it off. If I wanted 'use strict' in all my modules I would just add it myself. RyanCavanaugh commented on Jul 22, 2024 The setting that controls whether "use strict"; appears in your output is alwaysStrict, not noImplicitUseStrict copilotenstar commented on Jul 22, 2024
The setting that controls whether "use strict"; appears in your output is alwaysStrict, not noImplicitUseStrict
No...
"noImplicitUseStrict": true,
"alwaysStrict": false,
Search "use strict" (0 hits in 0 files of 34 searched)
"noImplicitUseStrict": false,
"alwaysStrict": false,
Search "use strict" (30 hits in 30 files of 34 searched)
I don't want to emit use strict in my files, why do you want to force it upon us so badly? RyanCavanaugh commented on Jul 22, 2024 Sorry, you're right (looks like something is wrong in the Playground wrt this)
Without "use strict"; in the output, your code can change runtime semantics in surprising ways that the checker won't detect.
why do you want to force it upon us so badly?
We really want your code to work! copilotenstar commented on Jul 22, 2024 I mean I get that part, but like, it's an option that some people use and it's been there for a very long time.
One reason I advocate for removing noImplicitUseStrict is that no one ever can remember what it actually does
Very serious reason to remove an optional that's already off by default...
I will just run another build step to strip it from all files afterwards I guess RyanCavanaugh commented on Jul 22, 2024 The stated reason was "non-strict-mode code is extremely rare in modern JS" and the longer reasoning outlined in #51909 was
This flag disables emitting a "use strict"; prologue at the top of module bodies when the target is not implicitly a module. This can lead to unexpected behavior since there are subtle behavioral differences between strict and nonstrict mode.
Fix: Remove any reliance on nonstrict behavior.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|