feat(51000) - Flag Deprecation Plan

[Oleksandr Tarasiuk (a-tarasyuk)]

Fixes#51000

[Oleksandr Tarasiuk (a-tarasyuk)]

Many tests don't set target explicitly and rely on the ES3, therefore, the PR contains many changes related to tests

TypeScript/src/harness/harnessIO.ts

Line 393 in 896b922

options.target=ts.getEmitScriptTarget(options);

TypeScript/src/compiler/utilities.ts

Lines 6361 to 6366 in 896b922

	exportfunctiongetEmitScriptTarget(compilerOptions: {module?: CompilerOptions["module"],target?: CompilerOptions["target"]}){
	returncompilerOptions.target||
	(compilerOptions.module===ModuleKind.Node16&&ScriptTarget.ES2022)||
	(compilerOptions.module===ModuleKind.NodeNext&&ScriptTarget.ESNext)||
	ScriptTarget.ES3;
	}

Is it acceptable to set globally ignoreDeprecations for tests?

[Jack Works (Jack-Works)]

Many tests don't set target explicitly and rely on the ES3, therefore, the PR contains many changes related to tests

can you create a new pr to explicitly set tests target to es5?

[Oleksandr Tarasiuk (a-tarasyuk)]

can you create a new pr to explicitly set tests target to es5?

I can, however many changes will remain due to the difference in output between es3 and es5.

[Jack Works (Jack-Works)]

can you create a new pr to explicitly set tests target to es5?

I can, however many changes will remain due to the difference in output between es3 and es5.

but that PR won't need to be reviewed clearly

[Jack Works (Jack-Works)]

I suggest to deprecate --experimentalDecorators and add a new flag --legacyDecorators to migrate

[Ryan Cavanaugh (RyanCavanaugh)]

Some notes from reviewing this:

• Thanks for taking this on!
• I'll send a PR shortly to change the default target to ES5. The test impact isn't too bad but it's big indeed.
• In general, I think this code is "too maintanable" as it were. We'll need to update these things every 2.5 years or so, so simply hardcoding the disallowed values altogether should be simpler to read IMO. The "phases" as we have them don't need to be manifested in the code; when 5.5 comes around we'll (hopefully) simply be deleting values from enums. Hope that makes sense and can make this a bit shorter.

[Oleksandr Tarasiuk (a-tarasyuk)]

In general, I think this code is "too maintanable" as it were. We'll need to update these things every 2.5 years or so, so simply hardcoding the disallowed values altogether should be simpler to read IMO. The "phases" as we have them don't need to be manifested in the code; when 5.5 comes around we'll (hopefully) simply be deleting values from enums. Hope that makes sense and can make this a bit shorter.

I've removed the parse versions in favor of the hardcoded versions and left only the type required for CompilerOptions. Maybe you have ideas for further simplification...

"too maintainable"

😂 - this is the first time I've seen such a polite synonym for "these changes don't meet expectations".

[Ryan Cavanaugh (RyanCavanaugh)]

I think the above comment is the only one I have left - LGTM otherwise. Great work!

[TypeScript Bot (typescript-bot)]

The TypeScript team hasn't accepted the linked issue #51000. If you can get it accepted, this PR will have a better chance of being reviewed.

[Andrew Branch (andrewbranch)]

Thanks Oleksandr Tarasiuk (@a-tarasyuk)!

[Ryan Cavanaugh (RyanCavanaugh)]

🎉!