Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Node 21 #234

Merged
merged 2 commits into from
Nov 9, 2023
Merged

Support Node 21 #234

merged 2 commits into from
Nov 9, 2023

Conversation

hyperupcall
Copy link
Contributor

@hyperupcall hyperupcall commented Nov 5, 2023

Modeled after #171, this adds support for Node21.

Side-note, I checked node.green, and found that Node.js 18.18.2, 19, and 20 all support ES2023. Should I update "target" of our corresponding presets to es2023 to match that, now that the value is supported by the latest TypeScript version?

Closes #231
Closes #209 (already fixed by #210)

@jakebailey
Copy link

jakebailey commented Nov 5, 2023

My impression is that the targets are set as the lowest common demoniator for any v18, v20, etc, releases (as in the oldest for each), so shouldn't be bumped. See also: https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping

Do note that changing the target after the fact can be breaking; es2023 wouldn't be supported in older TS releases. But, with the new versioning scheme where each major version starts with its own verison, it's not clear to me how any tsconfig package can have a breaking change in it anymore...

@hyperupcall
Copy link
Contributor Author

hyperupcall commented Nov 6, 2023

My impression is that the targets are set as the lowest common demoniator for any v18, v20, etc, releases (as in the oldest for each), so shouldn't be bumped.

That is a good point, so Node.js v18 would be off the table for updating. Now that I double-check, Node.green (and kangax compat table) is missing added features to ECMA2023, so I think it's better to be safe than sorry, and leave "target" as it was.

Do note that changing the target after the fact can be breaking; es2023 wouldn't be supported in older TS releases. But, with the new versioning scheme where each major version starts with its own verison, it's not clear to me how any tsconfig package can have a breaking change in it anymore...

Maybe I don't exactly understand what "new versioning scheme where each major version starts with its own verison" means, but tsconfig's README states that "We target the latest versions stable version of TypeScript... we can't always do semver releases". So my thoughts are that it is okay to assume valid values present in the latest stable version.

@orta
Copy link
Member

orta commented Nov 9, 2023

For new node's I think it's fine to introduce them at the latest version of TypeScript but as it's not complete support I think this is the right settings

Yeah, the lack of the ability to not do a semver break is a shame

@orta orta merged commit 84f659b into tsconfig:main Nov 9, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Node v21 support inconsistent case for "module" field in node bases
3 participants