feat(51000) - Flag Deprecation Plan

[a-tarasyuk]

Fixes #51000

[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

	export function getEmitScriptTarget(compilerOptions: {module?: CompilerOptions["module"], target?: CompilerOptions["target"]}) {
	return compilerOptions.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]

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?

[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]

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]

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

[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.

[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".

[RyanCavanaugh]

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

[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.

[andrewbranch]

Thanks @a-tarasyuk!

[RyanCavanaugh]

🎉!