search

tsconfig / bases

Hosts TSConfigs to extend in a TypeScript app, tuned to a particular runtime environment
MIT License
6.4k stars 240 forks source link

Support Node 21 #234

Closed hyperupcall closed 1 year ago

hyperupcall commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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