ES2023 missing for target in docs?

[thernstig]

Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

Caveat: I am not entirely sure where these faults stem from, but they have existed for some time and causes confusion for users. I am starting here.

From: https://www.typescriptlang.org/tsconfig

• es2023 is missing for target (but it should exist, see Add Array.prototype.findLast() and Array.prototype.findLastIndex() #49636)

If we use VS Code it reports that it cannot be used:

But https://json.schemastore.org/tsconfig has it.

I have no idea where the fault in VS Code comes from as it is/should be checking https://json.schemastore.org/tsconfig, and I also do not know why it was not included on From: https://www.typescriptlang.org/tsconfig.

It is possible I should split this up in more than one bug report, if this is a bug.

[RyanCavanaugh]

This is a bit confusing - the error message is auto-generated from the set of possible values that the parser knows about. Today esnext and es2023 are the same value, so it doesn't realize it needs to print them back separately since they're not long-term semantically identical, so just arbitrarily prints one or the other and picks esnext

While we're at it, we should remove es3 from the printback list.

[thernstig]

@RyanCavanaugh note there are two bugs then. The error message from the parser + the docs issue on https://www.typescriptlang.org/tsconfig.

Aside: Now that I understand the ts error seen in VS Code comes from the actual parser, it becomes weird in VS Code that they both print warnings and capitalization is different.

But that is because VS Code shows both errors from the ts parser as well the json schema from the schemastore. But it always bugged me they are capitalized differently as seen above.

Even more confusing is that it is capitalized differently in your own TypeScript docs compared to the ts parser output:

[fatcerberus]

I’ve always thought the all-lowercase variants were canonical, fwiw. I assume the camel-case versions probably originate from the TS source since there’s an enum for it. Though I guess ultimately the tsconfig parser doesn’t care about the capitalization.

Today esnext and es2023 are the same value

Wait, that doesn’t seem right. When I was working with the compiler API ESNext always had value 99 while all ES20xx were 0-based; there was never a case where one of them overlapped with ESNext. Has that changed?

[RyanCavanaugh]

Oh, I got messed up, ignore almost everything up there. OP is confusing lib and target -- es2023 is a valid lib, but isn't a valid target because there's nothing different between es2022 and es2023 re: syntax

[thernstig]

@RyanCavanaugh it could be labeled as confusion, but frankly how would one know reading this?

https://www.typescriptlang.org/tsconfig#target

"The target setting changes which JS features are downleveled and which are left intact"

Changing target also changes the default value of lib.

• What is "features" in this case? Does Array.prototype.findLast() and Array.prototype.findLastIndex() (Add Array.prototype.findLast() and Array.prototype.findLastIndex() #49636) not count as features? And thus do not need to be "downleveled"?
• Since target changes default value of lib, if I have "target": "es2022" then it cannot have "lib": "es2023 I assume, meaning I need to change lib manually?

Having Googled and looked around, there is a large amount of confusion around these settings as seen by SO questions etc.

Could the above target lib then be more specific exactly what it aims to "downlevel"?

[RyanCavanaugh]

New runtime methods (i.e. things that can be polyfilled) are not syntactic features.

if I have "target": "es2022" then it cannot have "lib": "es2023 I assume,

You can. Did you try it?

[thernstig]

New runtime methods (i.e. things that can be polyfilled) are not syntactic features.

@RyanCavanaugh By what definition? The top 10 Google results for javascript es6 features give e.g. Array.from() in a list of "ES features". A problem is how target is documented. There are many, many sites with headlines similar to "ecmascript features" that then goes about listing APIs. Even Node.js on release note blog post does this as an example, see https://nodejs.org/en/blog/announcements/v18-release-announce

the following new features are included ... The findLast() and findLastIndex() array methods.

Regarding:

You can. Did you try it?

I did try. But the core of the problem is this:

Changing target also changes the default value of lib.

I would suspect many users e.g. know they want to support es2023. Then they might go about their day and just set "target": "es2022" since they noticed that es2023 is not a valid option. But they might then forget to set "lib": ["es2023"].

Why not just include "target": "es2023" even if nothing new is happen, since that could then also change the default lib? Does that not make a lot of sense?

I could try to submit a PR to improve the docs of target if ok? Ideally though as well I feel es2023 should be part of the targets due to above mentioned reasons.

[RyanCavanaugh]

I'm trying to give you a definition. A new method is not a syntax.

Doc improvements always welcomed.

[typescript-bot]

This issue has been marked as "Question" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[thernstig]

I'm trying to give you a definition. A new method is not a syntax.

Doc improvements always welcomed.

I will give it a try soon.