fix: require Node v20.9.0+ [BREAKING CHANGE]#4484
fix: require Node v20.9.0+ [BREAKING CHANGE]#4484nolanlawson wants to merge 6 commits intomasterfrom
Conversation
package.json
Outdated
| }, | ||
| "volta": { | ||
| "node": "20.12.2", | ||
| "node": "22.7.0", |
There was a problem hiding this comment.
Locally, we may as well use a recent Node version. CI tests can still fail if we use something that doesn't work in Node 18.
There was a problem hiding this comment.
I usually prefer to use the oldest supported version. We're more likely to introduce code that works in a new version, but not an old one, than we are the reverse, and I don't like waiting for CI for an annoying (and usually trivial) error.
| ], | ||
| "engines": { | ||
| "node": ">=10" | ||
| }, |
There was a problem hiding this comment.
This config does nothing since the root monorepo package.json is private.
wjhsf
left a comment
wjhsf
left a comment
There was a problem hiding this comment.
Gotta love a good commit history 🧑🍳🤌
| uses: actions/setup-node@v3 | ||
| with: | ||
| node-version: '20.12.2' | ||
| node-version: '20.9.0' # earliest node version we support (via "engines" in package.json) |
There was a problem hiding this comment.
Is there any way we could read this from a file, so that we don't have to maintain it in multiple places? (Or just a single GHA env var...)
There was a problem hiding this comment.
Sadly I could not find a way to do this in GHA.
package.json
Outdated
| }, | ||
| "volta": { | ||
| "node": "20.12.2", | ||
| "node": "22.7.0", |
There was a problem hiding this comment.
I usually prefer to use the oldest supported version. We're more likely to introduce code that works in a new version, but not an old one, than we are the reverse, and I don't like waiting for CI for an annoying (and usually trivial) error.
| license: 'MIT', | ||
| publishConfig: { access: 'public' }, | ||
| engines: { | ||
| node: '>=20.9.0', |
There was a problem hiding this comment.
How strict is this version? Does the code fail to execute on 20.8 or earlier or is this just treadmilling?
There was a problem hiding this comment.
It will fail to npm install, so it's kind of a blocker for people with older Node versions.
The reason for 20.9.0 is that this limit is set by our devDependencies (I forget which one).
Technically devDeps don't matter for our consumers, but IME it's a huge pain to try to define one minimum Node version for your deps and another for your devDeps.
nolanlawson
changed the title
|
Perhaps this PR could change the tsconfig moduleResolution to "node16"? The "node" value is actually deprecated and is an alias to "node10". Although I'd probably just change it to "bundler". Line 9 in 5d1837b |
|
@cardoso This PR is about the code we ship to consumers, whereas |
|
Just re-checked and v20.9.0 is still the minimum version we can run. |
|
Replaced by #5636. |
4 participants
Details
BREAKING CHANGE: require Node v20.9.0+.
Node support calendar for reference.
This also updates our CI tests to test in the earliest version of Node that we can possibly support.
The reason for
20.9.0in particular is that it's the lowest version that all of ourdependencies/devDependenciessupport.Does this pull request introduce a breaking change?
Does this pull request introduce an observable change?