Add target: es2022

[saschanaz]

Suggestion

🔍 Search Terms

es2022

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

There are now some accepted proposals targeting ES2022.

📃 Motivating Example

Class fields, RegExp match indices, top level await

💻 Use Cases

Whatever.

[wgebczyk]

"Use Cases" ==> "Whatever" :D :D :D Maybe just remove section that is not needed/used...

[gabritto]

We would prefer to add ES2022 as a target at a later time, once the ES standard implementation is completed or unlikely to change.
The reason is that if we add ES2022 as a target now, we would need to implement a transformer for the target, but the proposals' implementations may still change and this would affect the transformer's implementation.

[gabritto]

@saschanaz
If there's a specific problem you have related to ES2022, e.g. adding something to lib.esnext.d.ts, you could create another issue just for that.

[saschanaz]

once the ES standard implementation is completed or unlikely to change.

I intended to cover only finished proposals in stage 4, and thus it shouldn't be a significant issue here. (AFAIK changing behavior of stage 4 proposals in any major way will break web compatibility and thus shouldn't occur.)