Infra: Use devEngines in root package.json and pin npm version in CI

[manzoorwanijk]

What?

Related to #72143. Redo of #76391, following its discussion.

Adds devEngines to the root package.json while keeping engines and the CI node_modules caching intact. Also pins the npm version in the remaining CI install paths.

Why?

Differing npm versions across contributors and CI cause behavior differences, particularly in package-lock.json (#72143). devEngines is the standard field for a development monorepo like this one, and unlike engines it fails npm install with a clear error when the Node.js/npm version doesn't satisfy the range. engines is kept because the w.org build server reads it.

How?

• Add devEngines (runtime + packageManager) to root package.json alongside engines.
• Let devEngines.packageManager drive actions/setup-node npm caching (auto-enabled), keeping the benchmarked node_modules cache from Speed up npm ci by caching node_modules #45932.
• Cache workspace node_modules via an explicit path list instead of a **/node_modules glob, which follows symlinks on isolated layouts and stalls the cache step.
• Extend the existing npm install -g npm@10 pin from static-checks.yml to all other CI install paths.

Testing Instructions

1. Set devEngines.runtime.version to a version higher than your installed Node.js and run npm install — it should fail with a clear error.
2. Repeat for devEngines.packageManager.version.
3. Confirm CI passes, including cache-hit runs.

Use of AI Tools

Written with the help of AI (Claude Code), reviewed and tested by the author.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: 0 B

Total Size: 7.72 MB

_{compressed-size-action}

[aduth]

This seems good for consistency 👍 I see it's doing a few different things already, and at the risk of adding one more thing: With where discussion was going in #72143, I thought I might see us pinning to v11 or v12 instead of v10. Is that something you want to do or we think is a good idea?

[github-actions]

Flaky tests detected in 8374e84.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29477959796
📝 Reported issues:

• [Flaky Test] should paste block styles using keyboard #78759 in /test/e2e/specs/editor/various/list-view.spec.js

[manzoorwanijk]

I thought I might see us pinning to v11 or v12 instead of v10. Is that something you want to do or we think is a good idea?

In this PR I just want to bring consistency, the switch to v11 or v12 can be done in a follow up PR if we are ready for that.

[aduth]

In this PR I just want to bring consistency, the switch to v11 or v12 can be done in a follow up PR if we are ready for that.

I think we'll be blocked by #72973 . I tried updating locally today and it failed on engines requirements:

npm i -g npm@latest
npm error code EBADENGINE
npm error engine Unsupported engine
npm error engine Not compatible with your version of node/npm: npm@12.0.1
npm error notsup Not compatible with your version of node/npm: npm@12.0.1
npm error notsup Required: {"node":"^22.22.2 || ^24.15.0 || >=26.0.0"}
npm error notsup Actual:   {"node":"v20.19.6","npm":"11.16.0"}

[manzoorwanijk]

I think we'll be blocked by #72973 . I tried updating locally today and it failed on engines requirements:

Yes, for v12, we need at least Node 22, but for v11, we are good.

[aduth]

This generally looks good to me, though with the reference to #76391 and especially the comment at #76391 (review), I'd be curious for @desrosj 's thoughts as well. My understanding is that this largely addresses the root concern by continuing to maintain engines in addition to devEngines.

[manzoorwanijk]

Yes, the idea is to make the changes additive and not break the existing setups. I think we can wrap this up once @desrosj reviews it and then we can start preparing the PRs for Node version upgrade via #72973 and then flip the version here to v11.

[manzoorwanijk]

Should we ship this to continue working on Node v24 changes?

It doesn't change or break anything.

[ciampo]

Looking at this, >=10.2.3 accepts newer npm majors when the runtime is compatible, while every new CI step uses the floating npm@10 selector.

Looking at the current Node 24 job, that selector installed 10.9.8; a contributor using npm 11 still satisfies this devEngines range. That preserves the version mismatch behind #72143, and a future npm 10 release can also change CI without any repository change.

So I feel that this PR's claim is not fully satisfied. If we merge as-is, we should leave #72143 open for the actual version-alignment follow-up. Otherwise, we could select one exact npm version in devEngines.packageManager.version ? The broader engines.npm range can remain for the build server if needed.

[manzoorwanijk]

Yes, that is intentional. We don't want to lock everyone with the old npm version if the latest one works fine. For example, currently, I am on npm v11 although the engines mention v10.

[manzoorwanijk]

I have updated the PR to avoid closing the related issue.

[ciampo]

LGTM 🚀

[manzoorwanijk]

OK, let us merge this and keep moving to v24 changes.