chore(ci): add Node 26 to build-lint-test matrix

[lisa-assistant]

Adds Node 26 to the build-lint-test CI matrix per @Tobbe's request.

Changes

• set-up-job action — adds a node-version input (default: '24') and passes it to actions/setup-node
• build-lint-test reusable workflow — adds a node-version workflow_call input and forwards it to set-up-job
• ci.yml — adds node-version: [24, 26] to the matrix (resolves to the latest patch for each major), updates the job name template

The change is purely additive — default behaviour for all other jobs is unchanged.

[netlify]

👷 Deploy request for cedarjs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	9e15060

[greptile-apps]

Greptile Summary

This PR extends the build-lint-test CI matrix to also run on Node 26 by parameterising the Node version through the set-up-job composite action and the build-lint-test reusable workflow. All existing jobs retain their Node 24 default, so non-matrix callers are unaffected.

• .github/actions/set-up-job/action.yml gains a node-version input (default '24') that is passed directly to actions/setup-node.
• .github/workflows/build-lint-test.yml gains a matching node-version workflow-call input forwarded to set-up-job.
• .github/workflows/ci.yml adds node-version: [24, 26] to the matrix and updates the job-name template accordingly.
• docs/implementation-docs/2026-03-26-cedarjs-project-overview.md still lists Node.js | version: 24 in the RUNTIME table; it does not yet reflect Node 26 coverage (flagged in a prior review comment).

Confidence Score: 4/5

Safe to merge with the caveat that the two node_modules cache-save keys in set-up-job still omit the Node version, which can cause cross-Node cache pollution on the new matrix entries.

The wiring from ci.yml → build-lint-test.yml → set-up-job is correct and the default behaviour for every non-matrix caller is unchanged. The open risk is in set-up-job: both cache-save keys are keyed only on OS and lock-file hashes. With two Node versions now sharing the same key space, whichever job saves the cache first will have its node_modules — including native addon binaries built against that Node ABI — restored by the other version. This can silently break packages like esbuild, @prisma/client, or better-sqlite3. These issues were flagged in prior review comments and remain unaddressed.

.github/actions/set-up-job/action.yml — both cache-save keys need the Node version incorporated before this matrix expansion is fully reliable.

Important Files Changed

Filename	Overview
.github/actions/set-up-job/action.yml	Adds node-version input (default '24') and passes it to actions/setup-node; both node_modules cache-save keys still omit the Node version and will collide across matrix entries.
.github/workflows/build-lint-test.yml	Adds node-version string input (default '24') and forwards it to the set-up-job composite action; no issues in the wiring itself.
.github/workflows/ci.yml	Adds node-version: [24, 26] to the matrix and updates the job name template; matrix integer values coerce correctly to the string input in build-lint-test.yml.

_{Reviews (2): Last reviewed commit: "chore(ci): add Node 26 to build-lint-tes..." | Re-trigger Greptile}

[nx-cloud]

🤖 Nx Cloud AI Fix

Ensure the fix-ci command is configured to always run in your CI pipeline to get automatic fixes in future runs. For more information, please see https://nx.dev/ci/features/self-healing-ci

---

View your CI Pipeline Execution ↗ for commit 9e15060

Command	Status	Duration	Result
nx run-many -t build:pack --exclude create-ceda...	✅ Succeeded	5s	View ↗
nx run-many -t build	✅ Succeeded	5s	View ↗
nx run-many -t test --minWorkers=1 --maxWorkers=4	✅ Succeeded	2s	View ↗
nx run-many -t test:types	✅ Succeeded	7s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-05-10 10:44:09 UTC

[greptile-apps]

Project overview doc lists only Node 24 as runtime version

docs/implementation-docs/2026-03-26-cedarjs-project-overview.md shows Node.js | version: 24 in the RUNTIME table. Now that CI officially tests Node 26 as well, that table entry may become stale and mislead contributors about supported runtime versions. Consider updating it to reflect both 24 and 26 (or whichever versions the project intends to support).

Context Used: Make sure everything in docs/implementation-docs/2... (source)

[Tobbe]

We can't upgrade to Node 26 yet because we use Yargs 17. See yargs/yargs#2509 and yargs/yargs#2514

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[Tobbe]

yargs/yargs#2509

We should be able to upgrade yargs now (if dependabot hasn't already), which would unblock this PR again