Skip to content

Tooling: admit Node 26 alongside Node 24 - #794

Merged
epeicher merged 1 commit into
trunkfrom
tooling/allow-node-26
Sep 11, 2026
Merged

Tooling: admit Node 26 alongside Node 24#794
epeicher merged 1 commit into
trunkfrom
tooling/allow-node-26

Conversation

@epeicher

@epeicher epeicher commented Sep 11, 2026

Copy link
Copy Markdown
Collaborator

What it does

Widens the Node pin in package.json from >=24 <25 to ^24.0.0 || ^26.0.0 (both engines and devEngines).

Rationale

devEngines with onFail: error makes npm refuse npm ci on a Node 26 machine before anything installs, so a reviewer on the current release line could not run the vitest suite at all. The pin exists to fail fast instead of silently churning the lockfile on a different Node major. Measured on Node 26.8.2, the lockfile rewrite is byte-for-byte the same one Node 24.16.0 produces, and build, lint, typecheck and the full vitest suite pass on both, so the reason for excluding 26 does not hold.

The range admits the two current release lines and skips Node 25, the odd line that is already end-of-life. onFail: error stays, so an unvalidated major (27) still fails fast.

Implementation

  • package.json: engines and devEngines.runtime.version become ^24.0.0 || ^26.0.0. .nvmrc and CI stay on 24, so shipped bundles are unchanged.
  • package-lock.json: regenerated. Besides mirroring the new engines value, this picks up the package name that was renamed to openstation in package.json but never in the lock, which is what made any npm install on trunk dirty the lockfile.

Testing instructions

  • On Node 24 (nvm use): npm ci && npm run build && npm run lint && npm run typecheck && npm run test:js all pass.
  • On Node 26 (nvm install 26 && nvm use 26): npm ci now succeeds where it previously failed with EBADDEVENGINES; the same four gates pass (500 test files, 6091 tests).
  • On either version, npm install --package-lock-only leaves the lockfile clean.
Open WordPress Playground Preview

@epeicher
epeicher force-pushed the tooling/allow-node-26 branch from 5d4b4f6 to a2d67cc Compare September 11, 2026 08:34
The devEngines pin (>=24 <25, onFail: error) refuses `npm ci` on a
Node 26 machine before anything installs, so a reviewer on the current
release line cannot run the vitest suite at all. The pin was added to
fail fast instead of silently churning the lockfile on a different Node
major; measured on Node 26.8.2, the lockfile rewrite is byte-for-byte
the same one Node 24.16.0 produces, and build, lint, typecheck and the
full vitest suite pass on both.

Widen `engines` and `devEngines` to `^24.0.0 || ^26.0.0`: the two
current release lines, skipping the end-of-life odd line in between.
`onFail: error` stays, so an unvalidated major still fails fast.
`.nvmrc` and CI stay on 24.

The lockfile regeneration also picks up the package name that was
renamed to `openstation` in package.json but never in the lock, which
is what made any `npm install` on trunk dirty the lockfile.
@epeicher
epeicher force-pushed the tooling/allow-node-26 branch from a2d67cc to 6ed488d Compare September 11, 2026 08:40
@epeicher
epeicher merged commit 0f10aab into trunk Sep 11, 2026
5 checks passed
@epeicher
epeicher deleted the tooling/allow-node-26 branch September 11, 2026 09:00
epeicher added a commit that referenced this pull request Sep 11, 2026
`PR Preview Publish` resolves the PR from the trusted `workflow_run`
payload and requires the PR's head to still be the exact commit the
build ran on. When a second push lands while the first build is still
running, that commit is superseded before the publish job starts, the
lookup matches nothing, and the step calls `core.setFailed`.

Nothing is actually broken when that happens: the newer commit's own
build/publish pair posts the preview, the job attaches no check run to
the PR, and it is not in the trunk ruleset's required checks. But
`workflow_run` runs are attributed to the default branch, so each race
paints a red run in the trunk Actions tab. It fired twice in two days
(#794, and a `codex/agent-async-jobs` push the day before), and it will
fire whenever anyone pushes twice in quick succession.

Warn and skip instead. The four steps that need a PR number are gated on
it, so the job ends green with an annotation saying the head moved on.
Publishing the superseded build under the current PR was never the
alternative: a reviewer clicking that preview would get older code.

The trust model is unchanged. A preview is still only ever published to
a PR positively identified from the payload, and the loud failures stay
loud: a malformed head SHA or incomplete head data still fails, and an
API or permission error throws out of `paginate` rather than returning
an empty list.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant