ci: publish on Node 24 with a pinned npm

[JohnMcLear]

The publish job ran on Node 25 and then ran npm install -g npm@latest. npm 12 requires Node ^22.22.2 || ^24.15.0 || >=26.0.0, which excludes Node 25, so once npm 12 shipped that step died with EBADENGINE and this package could no longer be published:

npm error code EBADENGINE
npm error Not compatible with your version of node/npm: npm@12.0.2
npm error Required: {"node":"^22.22.2 || ^24.15.0 || >=26.0.0"}
npm error Actual:   {"node":"v25.9.0","npm":"11.12.1"}

This moves the job to Node 24 (an LTS line every npm 11.x and 12.x supports) and pins the upgrade to npm@^11.5.1 — a range rather than @latest, so the next npm major dropping this Node line cannot silently break publishing fleet-wide again. npm >= 11.5.1 is what OIDC trusted publishing needs.

Same fix as the pilot, ether/ep_align#227.

🤖 Generated with Claude Code

https://claude.ai/code/session_013S4pYSjwUsiZtdtMMpW7bw

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Fix npm publishing with Node 24 and pinned npm 11

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Moves publishing from unsupported Node 25 to the Node 24 LTS line.
• Pins npm to compatible 11.x releases while preserving OIDC trusted publishing.

Diagram

graph TD
  A["Publish Job"] --> B["Node 24 LTS"] --> C["npm 11 Range"] --> D["OIDC Publish"]

Loading

High-Level Assessment

The chosen approach is appropriate: Node 24 provides an LTS runtime compatible with the required npm versions, while the ^11.5.1 constraint preserves OIDC support without exposing publishing to incompatible future npm majors. Using Node 22 or an exact npm patch would be unnecessarily restrictive, while retaining npm@latest would recreate the original failure mode.

Files changed (1) +9 / -5

Bug fix (1) +9 / -5

npmpublish.ymlUse Node 24 and constrain npm to compatible 11.x releases +9/-5

Use Node 24 and constrain npm to compatible 11.x releases

• Changes the publishing runtime from Node 25 to Node 24 LTS and replaces npm@latest with npm@^11.5.1. Expanded comments document the EBADENGINE failure and explain why the npm major is constrained.

.github/workflows/npmpublish.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Publishing regressions go undetected 📘 Rule violation ▣ Testability

Description

.github/workflows/npmpublish.yml changes the previously failing publish environment to Node 24 and
npm@^11.5.1, but the change set adds no automated regression test for that compatibility
constraint. A future runtime or npm-range edit can reintroduce the EBADENGINE scenario without the
normal test suite catching it before the publish job runs.

Code

.github/workflows/npmpublish.yml[R28-33]

+          node-version: 24
         registry-url: https://registry.npmjs.org/
+        # Pinned to a range rather than @latest: the next npm major dropping
+        # this Node line would silently break publishing fleet-wide again.
     - name: Upgrade npm to >=11.5.1 (required for trusted publishing)
-        run: npm install -g npm@latest
+        run: npm install -g npm@^11.5.1

Evidence

PR Compliance ID 565485 requires every behavior-changing bug fix to include a regression test in the
same change. The cited workflow lines replace the incompatible Node 25 and latest-npm setup, while
the complete change set contains no new or modified automated test.

Rule 565485: Every bug fix must include a regression test in the same change
.github/workflows/npmpublish.yml[23-33]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The publish workflow fixes an npm and Node compatibility failure without adding an automated regression test that protects the required version relationship.
## Fix Focus Areas
- .github/workflows/npmpublish.yml[23-33]
## Recommended Fix
Add a test wired into the normal test suite that reads the publish workflow and asserts it selects the supported Node 24 line and constrains the npm upgrade to major version 11 at or above 11.5.1. Ensure the test fails for the former Node 25 and `npm@latest` combination.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Publishing regressions go undetected 📘 Rule violation ▣ Testability

.github/workflows/npmpublish.yml changes the previously failing publish environment to Node 24 and
npm@^11.5.1, but the change set adds no automated regression test for that compatibility
constraint. A future runtime or npm-range edit can reintroduce the EBADENGINE scenario without the
normal test suite catching it before the publish job runs.

Agent Prompt

## Issue description
The publish workflow fixes an npm and Node compatibility failure without adding an automated regression test that protects the required version relationship.

## Fix Focus Areas
- .github/workflows/npmpublish.yml[23-33]

## Recommended Fix
Add a test wired into the normal test suite that reads the publish workflow and asserts it selects the supported Node 24 line and constrains the npm upgrade to major version 11 at or above 11.5.1. Ensure the test fails for the former Node 25 and `npm@latest` combination.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools