ci: pin subgraph deploy workflows to Node 22

[levalleux-ludo]

Fixes the npm ci failure in run 32975075125, where the subgraph deploy job failed immediately after #1037 merged:

npm error Invalid: lock file's typescript@5.8.3 does not satisfy typescript@5.9.3

It isn't the release commit

The obvious suspect was a63c3cc0 (chore(release): publish alpha), pushed by the publish job moments before the deploy job ran. It isn't. I extracted the manifests from both commits and ran npm ci --dry-run against each:

commit	npm 10.9.3	npm 11
e56d4582 — the #1037 merge, before the release commit	—	❌ Invalid: lock file's typescript@5.8.3 does not satisfy typescript@5.9.3
a63c3cc0 — the release commit	✅ added 4049 packages	❌ same error

The commit before the release commit fails identically. The variable is the npm version, not the tree.

Root cause

deploy-{testing,staging,prod}-subgraph.yaml were on node-version: "24"; ci.yaml, publish-alpha.yaml, pin-to-pinata.yaml and the root package.json volta config (node 22.18.0 / npm 10.9.0) are all on 22. Node 24 ships npm 11.

The root package.json declares overrides: { "typescript": "^5.1.6", … } and the lock pins typescript 5.8.3. npm 11 resolves that override to a concrete version — 5.9.3, the newest 5.x, published 2025-09-30 — and rejects the lock. npm 10 never performs that check, which is why publish-alpha.yaml installed the very same lock cleanly minutes earlier. No package.json in the tree declares 5.9.3; I grepped it.

Why it surfaced now: the deploy job only runs when packages/subgraph/** changes (SUBGRAPH_CHANGES == 'true'), so #1037 was the first Node 24 npm ci against this lock since typescript 5.9.3 was published.

Why not regenerate the lock

The two npm majors want mutually incompatible locks:

lock generated by	npm 10	npm 11
npm 10 (current)	✅	❌ Invalid: lock file's typescript@5.8.3 does not satisfy typescript@5.9.3
npm 11	❌ Missing: typescript@4.9.5 from lock file	✅

They disagree over whether the root overrides.typescript: "^5.1.6" applies inside e2e/opensea-api-mock, which asks for typescript: "^4.8.3". npm 10 keeps a nested typescript 4.9.5 for it; npm 11 applies the override and drops it. No single lock satisfies both, so regenerating just moves the breakage onto ci.yaml and publish-alpha.yaml.

The change

node-version: "24" → "22" in the three subgraph deploy workflows, plus a comment so this doesn't drift again. Nothing in the deploy path needs 24 — @graphprotocol/graph-cli declares engines.node >= 20.18.1 and @goldskycom/cli declares none. The 24 came in incidentally via #997 (npm trusted-publishing work), which left the publish and CI workflows on 22.

Staging and prod were carrying the identical latent failure, so all three are fixed together.

Verification

• npm ci --dry-run passes under npm 10.9.3 against the current main tree — that is exactly what these workflows will now run
• workflows: YAML parses, prettier --check clean, actionlint reports only pre-existing findings

Follow-ups, not in this PR

• Move the repo to npm 11 deliberately — resolve the override / e2e/opensea-api-mock conflict, regenerate the lock, and bump every workflow together. Worth doing before Node 22 goes EOL.
• actionlint flags actions/{checkout,setup-node,cache}@v3 in all three of these workflows as too old to run. The rest of the repo is on v4; these are the only holdouts.
• The deploy job checks out refs/remotes/origin/main — the moving branch tip — rather than github.sha, so it installed a63c3cc0 while the publish job installed e56d4582. Not the cause here, but a called workflow silently building a newer main than the one that triggered it is a hazard for a release pipeline.

🤖 Generated with Claude Code