You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Framework: Update Node.js version to v24 LTS #72973
The project is currently configured to expect Node.js v20 (minimum version v20.10.0).
This produces a few challenges:
It's inconsistent with our documentation, which frequently references that we aim to target the current active LTS (example)
It prevents the use of new features and bug fixes in more recent versions of Node.js
Which in turn can introduce the potential for bugs due to lack of awareness of said feature differences (example)
Version drift increases future overhead when eventually reconciling the drift, and puts us at risk of falling outside the window of support (Node.js v20 will be end-of-life in April 2026)
What is your proposed solution?
Update the expected version of Node.js to v24.x, the current Active LTS.
An additional step I'd recommend is changing the .nvmrc to specifically pin to the version of Node.js used on WordPress build servers, to ensure everyone is using the same version and to ensure compatibility across build environments.
Some of the work to support this has already been completed in #71091 (namely, adding v24 to the CI build matrix to help ensure code compatibility).
An additional step I'd recommend is changing the .nvmrc to specifically pin to the version of Node.js used on WordPress build servers, to ensure everyone is using the same version and to ensure compatibility across build environments.
Do you mean a specific version number, like 24.0.0, or major.minor, or something else?
I like targeting a specific version. Volta follows this approach (I've advocated for Volta support in the past). It helps folks in the future to know what version was used for a given commit which is very helpful if you've ever tried to build an older commit of a project like this.
A summary of reasons why update to Node.js 24 will be a significant security and quality-of-life improvement:
full native support for ES modules, including mutual interop between ES and CJS modules. Some of these features get backported to the 20.x and 22.x lines, but 24.x has the full set.
running TypeScript files natively, with built-in type stripping, with no need for transpilation.
new native API for filesystem and crypto that can replace NPM packages. fast-glob, uuid, rimraf, mkdirp, node-fetch packages can be replaced. Improves devex and also security, because popular NPM packages are a target for supply-chain attacks.
NPM 11 (bundled by default with Node.js 24) supports "Trusted publishing" of NPM packages from CI, very useful for publishing Gutenberg packages from GitHub actions.
Node.js 24 fixes some floating point calculation bugs (like Math.pow) where previous versions give bad results. Can be a pain for unit test snapshots.
new APIs like findPackageJSON that can simplify build tooling.
These are all practical problem we're regularly running into when working in the Gutenberg repo.
@jsnajdr Thank you! This list is super helpful and makes the case to upgrade more compelling.
In order to make this process easier now and in the future, I've spent some time this week drafting a new page for the Core Handbook that details the upgrade process and any surrounding factors that should be considered/weighed.
I had mentioned this to @aduth in Slack, but I would love to get a few reviews from contributors who have and have not helped with this process before. We can also refer to this new page as we go through the process for this upgrade to make sure nothing was missed or is inaccurate.
I'm going to work on the request to the systems team next.
Reacted by Andrew Duthie, Weston Ruter and Manzoor Wani
While Node.js 20.x is going to be removed from the GitHub Actions runner images, only actions themselves are required to utilize the specific versions included on the runners by default.
The actions/setup-node action first attempts to use the pre-installed versions of Node.js/npm when possible, but it falls back to checking the download cache, and then ultimately downloading the version directly from Node.js when it's not already present and available.
If we haven't started on this yet, can we please hold off for a few days to ensure we have the required npm version (v11.11.1) needed for #76195?
This may be possible, but it would require some communication to contributors. In the past when we have chosen to pin the most recent version of Node.js/npm it has caused some problems. Mainly, nvm will be satisfied with 24.11.0 if 24 is specified in the .nvmrc file, but it will cause an error if 24.12.0 is in engines.node.
Also, I'm not familiar with how Node.js decides when to bump the version of npm bundled in each version, but historically the version in engines.npm has always represented the version bundled with the defined engines.node version. I'm not familiar with a way to easily manage the npm version independently of that.
I recognize that this is blocked by me. My apologies that I haven't gotten to it. I have the related tasks on my list to get to next week.
For a Make/Core post, since you've driven a lot of work on this, I think it could be good to come from you.
Sure, I would love to help. I can draft things and share them here, and then you can post them on Make/Core because I don't have write access.
I think we could probably coordinate to get you publishing access, especially since you've been driving a lot of impactful framework-level work that affects other developers who would be subscribed to Make/Core.
The post looks great! I left a handful of small-ish review comments inline in the document. I like how you've outlined all of the benefits of what the upgrade will include.
This needs some correction. As I mentioned in #72143 (comment), npm v12 will not be backported to Node v26. So, we will need to explicitly/manually update to npm v12 on the build server as well as in the repos.
Ah yes, apologies for that mix up!
Thanks for starting the document, @manzoorwanijk! I'll take a look during my Wednesday.
Activity
sirreal commentedon Nov 4, 2025
Do you mean a specific version number, like 24.0.0, or major.minor, or something else?
I like targeting a specific version. Volta follows this approach (I've advocated for Volta support in the past). It helps folks in the future to know what version was used for a given commit which is very helpful if you've ever tried to build an older commit of a project like this.
aduth commentedon Nov 4, 2025
Yeah, the idea being that if our
.nvmrctoday specified20.10.0(instead of20), I wouldn't be fixing things reactively like in #72971.[-]Update Node.js version to v24 LTS[/-][+]Framework: Update Node.js version to v24 LTS[/+]SirLouen commentedon Dec 27, 2025
I was talking about this with @youknowriad recently.
Furthermore, npm should be updated to 11. Maybe both things could be coordinated simultaneously.
I would bring this in the next
dev-chat(I'm not sure when it is, not sure if 31st of December or 7th of January).jsnajdr commentedon Jan 5, 2026
One new reason why we'll need to update Node.js is supporting the Trusted Publishers auth scheme for publishing packages to NPM:
https://docs.npmjs.com/trusted-publishers
It requires NPM CLI 11.5.1, which ships only with the Node.js 24 line. The 22 line ships version 10.
jsnajdr commentedon Jan 15, 2026
A summary of reasons why update to Node.js 24 will be a significant security and quality-of-life improvement:
fast-glob,uuid,rimraf,mkdirp,node-fetchpackages can be replaced. Improves devex and also security, because popular NPM packages are a target for supply-chain attacks.Math.pow) where previous versions give bad results. Can be a pain for unit test snapshots.findPackageJSONthat can simplify build tooling.These are all practical problem we're regularly running into when working in the Gutenberg repo.
desrosj commentedon Jan 16, 2026
@jsnajdr Thank you! This list is super helpful and makes the case to upgrade more compelling.
In order to make this process easier now and in the future, I've spent some time this week drafting a new page for the Core Handbook that details the upgrade process and any surrounding factors that should be considered/weighed.
I had mentioned this to @aduth in Slack, but I would love to get a few reviews from contributors who have and have not helped with this process before. We can also refer to this new page as we go through the process for this upgrade to make sure nothing was missed or is inaccurate.
I'm going to work on the request to the systems team next.
Fix missing dependencies for packages (#74310)
manzoorwanijk commentedon Mar 10, 2026
If we haven't started on this yet, can we please hold off for a few days to ensure we have the required npm version (
v11.11.1) needed for #76195?aduth commentedon Mar 13, 2026
Noting that GitHub is planning to remove Node 20 as an option for GitHub Actions runners in "the fall of 2026".
desrosj commentedon Mar 13, 2026
The way they communicate these changes is really confusing. I've asked that team for clarity around that before.
While Node.js 20.x is going to be removed from the GitHub Actions runner images, only actions themselves are required to utilize the specific versions included on the runners by default.
The
actions/setup-nodeaction first attempts to use the pre-installed versions of Node.js/npm when possible, but it falls back to checking the download cache, and then ultimately downloading the version directly from Node.js when it's not already present and available.This may be possible, but it would require some communication to contributors. In the past when we have chosen to pin the most recent version of Node.js/npm it has caused some problems. Mainly,
nvmwill be satisfied with24.11.0if24is specified in the.nvmrcfile, but it will cause an error if24.12.0is inengines.node.Also, I'm not familiar with how Node.js decides when to bump the version of npm bundled in each version, but historically the version in
engines.npmhas always represented the version bundled with the definedengines.nodeversion. I'm not familiar with a way to easily manage the npm version independently of that.I recognize that this is blocked by me. My apologies that I haven't gotten to it. I have the related tasks on my list to get to next week.
77 remaining items
aduth commentedon Aug 31, 2026
I think we could probably coordinate to get you publishing access, especially since you've been driving a lot of impactful framework-level work that affects other developers who would be subscribed to Make/Core.
Framework: Update Node.js to v24 LTS and npm to v11
Framework: Test Node.js 24 and 26 in CI matrices
manzoorwanijk commentedon Sep 1, 2026
Just noting here that I am working on these and will post here once ready. This is to avoid any duplicated effort on this.
manzoorwanijk commentedon Sep 1, 2026
Here is the Google Doc for Make Core post. Feel free to make any suggestions on the doc.
aduth commentedon Sep 1, 2026
The post looks great! I left a handful of small-ish review comments inline in the document. I like how you've outlined all of the benefits of what the upgrade will include.
manzoorwanijk commentedon Sep 1, 2026
Thank you for the review. I have implemented the suggestions and also made a correction commit in the PR.
desrosj commentedon Sep 2, 2026
Ah yes, apologies for that mix up!
Thanks for starting the document, @manzoorwanijk! I'll take a look during my Wednesday.
In the mean time, I've gone and added you to the Make WordPress Core site as an author. Please also review the Post & Comment Guidelines page in the handbook when you have a chance.
manzoorwanijk commentedon Sep 2, 2026
Thanks
Framework: Update Node.js to v24 LTS and npm to v11
Framework: Test Node.js 24 and 26 in CI matrices
Framework: Update Node.js to v24 LTS and npm to v11
Framework: Test Node.js 24 and 26 in CI matrices
Framework: Update Node.js to v24 LTS and npm to v11
Framework: Test Node.js 24 and 26 in CI matrices