As of September 8th, the versions of Node.js and npm required for WordPress development are now 24.x (minimum 24.18.0) and 11.x (minimum 11.16.0).

This applies to trunk in both repositories, the wp/7.1 branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". in gutenberg, and the 7.1 branch in wordpress-develop. Older branches remain unchanged (requiring >=20.10.0 and >=10.2.3 of Node.js and npm, respectively). See “What’s next” below for details on the long-term plan.

Here is a list of steps that you may need to take to continue contributing to WordPress:

1. Update your local environment to a version of Node.js >=24.18.0.
   • With nvm, run nvm install && nvm use inside your wordpress-develop or gutenberg checkout to pick up the version from .nvmrc, then reinstall dependencies with npm ci.
   • Similar commands exist if you use fnm (Fast Node Manager): fnm install && fnm use.
2. If you have an open pull request, merge or rebase the latest trunk into it. In Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, the required CI checks now run on Node.js 24, so PRs based on an older trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. will not contain the required checks until updated merging will be blocked by the repository’s configured rulesets.

The .nvmrc files temporarily pin 24.18 (major.minor) to make it easier for contributors to have the required version when they use nvm use. It will be relaxed to the major version later, per the upgrade handbook page.

While running the most recent version of any software is highly desirable, sometimes it’s perfectly fine to remain on a stable, supported version. While 20.x has not been Active LTS since October 2024, it has remained a Maintenance LTS release until reaching end-of-life in April 2026. As a result, packages and ecosystems have begun to drop support (GitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ announced the removal of 20.x from Actions runner images), and a growing queue of tooling and security work has combined to make running more modern versions a necessity.

Over the past year, PR-72973 accumulated a long list of work blocked on these versions. Highlights:

1. Isolated dependencies (PR-76195): switching Gutenberg to npm’s linked install-strategy so packages can only import what they declare. This closes a six-year class of “works in the monorepo, breaks for consumers” bugs in the published @wordpress/* packages. The implementation (PR-75814) has been ready since February and kept rebased against trunk the whole time. That continuous testing surfaced bugs in npm’s isolated mode and led to three major features contributed upstream to npm 12, so the tooling is ready the moment we flip the switch.
2. OIDC trusted publishing (PR-77227): publishing the @wordpress/* packages from CI without a long-lived npm token, eliminating a whole category The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of supply-chain risk. Requires npm 11.5.1+.
3. Supply-chain hardening for every contributor: the minimumReleaseAge protection already configured in Gutenberg only takes effect on npm 11, so it now applies to every local install A local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer., not just CI.
4. TypeScript without a build step: Node.js 24 runs TypeScript natively via type stripping. With the coding guidelines recommending TypeScript for new code, scripts and tools can be written in TS and executed directly.
5. Queued dependency updates that require Node.js 22+: Lerna 10, Lighthouse 13, webpack-dev-server 6, markdownlint-cli, and others.
6. Platform improvements: full ES module/CommonJS interop, and native glob, fetch, and crypto APIs that let us drop packages like rimraf, fast-glob, uuid, and node-fetch, shrinking the dependency tree that supply-chain attacks target.
7. npm 12 locally: npm 12’s Node.js requirement (^22.22.2 || ^24.15.0 || >=26.0.0) is now satisfied, so contributors can adopt its install-time security improvements today.

This is just the first step in this plan to upgrade the WordPress codebase to use the latest versions of Node.js. Here is an outline of the tasks that are targeted next.

When choosing which version to target, the guidance is to only choose versions with Active LTS status (currently 24.x). 26.x will be given this status later this year, in October. The goal is to ride the momentum from this change and upgrade to 26.x at that time.

The relevant workflows in both repositories will be updated to run the relevant tests against Node.js 26 to get a head start on this effort.

In general, the goal is for the underlying tools to be as consistent as possible across all versions of WordPress that are eligible to receive security patches. This includes the versions of Node.js and npm whenever possible, provided upgrading does not result in changes to the user-facing software.

Contributors have begun exploring the feasibility of updating Node.js to 24.x in the 6.4-7.0 branches of WordPress (and wp/X.Y branches in gutenberg), all of which currently use 20.x. The hope is that all of these branches can also be updated to 26.x in October along with trunk. 

The 6.3-4.7 branches will remain on Node.js 14.x and there are currently no plans to upgrade them.

As detailed above, the jump to 11.16.0 unlocks several security features. Security-focused work has continued into npm 12.x with install-time improvements.

The Node.js team recently announced that npm 12 will not be bundled with Node.js 26. Historically, the minimum version of npm required to contribute to WordPress has been set to the version bundled with the respective Node.js version. This avoids making the requirement more complicated than it needs to be, and contributors are always free to run any version that satisfies the minimum.

Because these security features are significant, the goal is to raise the minimum required version of npm to 12.x to ensure that everyone contributing to WordPress benefits from these security features.

Because this deviates from the historical practice, it requires some exploration to ensure that the w.org build server and explicit pins in each relevant repository all work as intended. That roadblock is already been cleared in the gutenberg repository when PR-82235 made devEngines.packageManager in package.json the single source of truth for the npm version that CI and the release tooling install. Moving Gutenberg to npm 12 now becomes a one-line change.

Because this upgrade may involve more changes due to enhanced security measures, upgrading this independent of Node.js will likely make this more manageable.

Starting with version 27.x, Node.js will move from two major releases per year to one major release per year and the odd/even distinction is eliminated. Future upgrades will be planned around that cadence.

1. The update initially landed in the Gutenberg repository through PR-80395 but was reverted due to some unanticipated Actions workflow failures in older numbered branches of wordpress-develop. These were addressed in #66040, and the changes were merged again in gutenberg through PR-82370. In wordpress-develop, the upgrade landed in r63539/#65451.

Preparing for this update took a considerable amount of time and effort. Thank you to everyone involved for helping to make WordPress better and easier to maintain. There are awesome things ahead.

Questions or problems after updating? Comment here or ask in #core-editor.

Props to @aduth, @desrosj, @jsnajdr, @jonsurrell, @mciampini, @tyxla, @mamaduka for driving and reviewing this work, @aduth and @desrosj for reviewing this post, and to the WordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Systems team for preparing the build servers for the new version of Node.js.

#build-test-tools, #gutenberg, #node-js, #npm