Upgrading WordPress Core Development Environments to Node.js 24 and npm 11

WordPress Development Tooling Requirements: Node.js 24 and npm 11

As of September 8th, the minimum tooling requirements for contributing to WordPress core and the Gutenberg editor have shifted. Development on main development branches now officially requires Node.js 24.x (with a strict minimum of 24.18.0) and npm 11.x (with a minimum of 11.16.0). This version shift impacts trunk in both the wordpress-develop and gutenberg repositories, as well as the wp/7.1 branch in Gutenberg and the 7.1 release branch in wordpress-develop.

Older maintenance branches currently remain set to their existing baselines, requiring Node.js >=20.10.0 and npm >=10.2.3. While Node.js 20.x was assigned Maintenance LTS status following October 2024, ecosystem deprecations—such as GitHub Actions removing Node 20.x from standard runner images—and growing security overhead necessitated this baseline escalation across active development tracks.

Local Environment Migration: Step-by-Step CLI Commands

Contributors working locally must update their active runtime and package management binaries to align with repository configurations. Modern Node environment managers parse the repository’s .nvmrc file, which currently pins version 24.18 (major.minor) to ensure consistent local installations before later relaxing to major version matching.

If you use Node Version Manager (nvm), navigate to your root wordpress-develop or gutenberg repository directory and execute:

nvm install && nvm use
npm ci

For developers utilizing Fast Node Manager (fnm), the equivalent execution chain is:

fnm install && fnm use
npm ci

Executing npm ci ensures that local node_modules trees strictly adhere to the updated lockfiles generated under the npm 11 specification.

Impact on Open Pull Requests and CI/CD Workflows

The upgrade directly alters automated continuous integration (CI) workflows on GitHub. Gutenberg’s required status checks and repository rulesets now run on Node.js 24 environments. Open pull requests created prior to this baseline shift will fail required checks or find merges blocked until rebased against updated upstream branches.

To unblock open contributions in Gutenberg or wordpress-develop, sync your local feature branch with the latest upstream trunk and push the update to GitHub:

git checkout main
git pull upstream trunk
git checkout feature/my-open-pr
git rebase main
git push --force-with-lease

The initial migration (PR-80395 in Gutenberg) was briefly reverted due to GitHub Actions workflow failures occurring in older numbered branches within wordpress-develop. After resolving these workflow edge cases under ticket #66040, the upgrade officially landed in Gutenberg via PR-82370 and in wordpress-develop via changeset r63539 (#65451).

Unblocking Core Architectural Upgrades and Isolated Dependencies

Adopting Node 24 and npm 11 unblocks a long queue of architectural modernizations that were previously blocked by older Node 20 limitations (accumulated under PR-72973). Chief among these is isolated dependencies (PR-76195).

By transitioning Gutenberg to npm’s linked install strategy, packages are restricted to importing only the exact dependencies explicitly declared in their respective package.json files. This architectural guardrail resolves a six-year-old class of monorepo bugs where published @wordpress/* packages would crash for external consumers due to undeclared, transitively leaked internal dependencies.

The underlying implementation (PR-75814) was held in continuous testing since February. This extended testing surfaced upstream edge cases in npm’s isolated install engine, directly prompting three core feature contributions upstream to npm 12.

Supply Chain Security Hardening and OIDC Publishing

Upgrading the default package manager to npm 11 introduces mandatory supply-chain security enhancements across both CI runners and local contributor environments:

• OIDC Trusted Publishing (PR-77227): Automated release tasks for @wordpress/* packages can now utilize OpenID Connect (OIDC) federated publishing from GitHub Actions. This removes the need for long-lived, static npm authentication tokens stored in repository secrets, requiring npm 11.5.1+.
• Local Enforced minimumReleaseAge: Gutenberg’s minimumReleaseAge configuration prevents the immediate installation of newly published packages to mitigate zero-day dependency supply-chain attacks. Under npm 11, this policy natively executes during local npm install or npm ci operations rather than applying solely to CI environments.
• npm 12 Compatibility: Running Node.js 24 satisfies npm 12’s engine requirements (^22.22.2 || ^24.15.0 || >=26.0.0), allowing contributors to opt into experimental npm 12 security features locally.

Native Execution and Dependency Cleanup in Node.js 24

Node.js 24 includes native runtime features that significantly streamline the WordPress build pipeline and strip out legacy third-party utility packages.

• Native TypeScript Execution (Type Stripping): Node 24 natively parses TypeScript files by stripping type annotations at runtime without requiring an ahead-of-time compilation step. Build scripts and developer utility tools written under WordPress TypeScript coding guidelines can now execute directly via Node.
• Standard API Expansion: Native runtime support for globbing, Fetch, and Web Crypto APIs allows core build tools to drop external packages, including rimraf, fast-glob, uuid, and node-fetch. Eliminating these direct dependencies directly reduces the surface area for potential supply-chain attacks.
• Tooling Version Upgrades: Unblocks mandatory updates for key development utilities requiring Node 22+, including Lerna 10, Lighthouse 13, webpack-dev-server 6, and markdownlint-cli.

Future Roadmap: Node 26 Migration and Upstream Cadence

The transition to Node.js 24 represents an interim step toward maintaining alignment with Active LTS releases. The WordPress core project targets an upgrade to Node.js 26.x in October, matching the window when Node 26 achieves official Active LTS status.

Additionally, the Node.js project has altered its release cadence starting with version 27.x. Upstream Node releases will transition from two major releases per year (with odd/even status distinctions) to a single major release per year. Future WordPress core environment upgrades will adapt directly to this simplified annual release cycle.

Backport Strategy Across Historical WordPress Branches

To keep maintenance channels secure, core contributors are investigating backporting Node.js 24.x updates across historical release branches (WordPress 6.4 through 7.0, along with corresponding wp/X.Y Gutenberg branches). The long-term objective is to align all active security-supported branches onto Node 26.x once October LTS status is established.

In contrast, legacy WordPress branches spanning 4.7 through 6.3 remain pinned to Node.js 14.x. There are no plans to alter runtime baselines for these legacy releases.

Independent Upgrades for npm Minimum Versions

Historically, the required minimum npm version for WordPress development was bound directly to the npm version bundled by default with the targeted Node.js release. However, due to critical install-time security enhancements introduced in npm 12—and the Node.js team’s decision not to bundle npm 12 inside Node 26—WordPress is decoupling its package manager requirements.

Following PR-82235, Gutenberg uses devEngines.packageManager within package.json as the single source of truth for repository tooling versions. This change enables the build infrastructure and CI pipelines to bump the baseline npm version to 12.x independently of underlying Node runtime upgrades through a single-line configuration change.

Primary reference: Review the original announcement for exact release details. This article is an independent explanation and does not reproduce the source text.