ci: migrate to pnpm/setup@v1 action

[lanesawyer]

Stacked last in stack #290: #289 (pnpm 11) → #198 (lefthook) → this PR. Base is lane/lint-fix-and-pre-commit-hooks, so review only the top commit. Merge the two below first.

What

Replaces the per-job pnpm/Node setup boilerplate in every workflow with the single pnpm/setup@v1 action, and moves the toolchain pins into package.json.

How

Workflows — every job had the same three steps:

- uses: pnpm/action-setup@v6
  with: { version: 11.21.0 }
- uses: actions/setup-node@v6
  with: { node-version: 24.15.0 }
- run: pnpm install --frozen-lockfile

replaced by:

- uses: pnpm/setup@v1
  with:
      cache: true

The action installs the runtime (replacing actions/setup-node), reads Node from devEngines.runtime and pnpm from packageManager, and runs pnpm install itself. That drops 8 duplicated version pins — #289 had to bump every one by hand; the next bump is a one-line package.json change.

All 8 jobs across ci.yml (5), deploy_examples.yml, publish.yml, and release.yml need dependencies, so all use cache: true; none qualified for install: false.

package.json — the two fields the action reads:

"packageManager": "pnpm@11.21.0",
"devEngines": { "runtime": { "name": "node", "version": "24.15.0", "onFail": "warn" } }

volta is left alone so Volta users keep working.

Why onFail is warn, not download

Worth calling out, because download is the more obvious choice and it fails CI.

With onFail: "download", pnpm treats the runtime as a project dependency: it adds a node: runtime:24.15.0 entry to the lockfile and installs Node into node_modules/.bin/node. That entry resolves to a multi-platform variations list, and the binary linked on the Linux runner was the host-architecture one, so every job died at the first parcel invocation:

node_modules/.bin/parcel: exec: node_modules/.bin/node: Exec format error

This does not reproduce locally on macOS — the linked binary happens to be the correct one there — so it only showed up on CI.

warn is the right value regardless: the action already installs the runtime, so having pnpm install a second Node into node_modules is redundant. It also keeps devEngines advisory rather than hard-failing contributors whose Node is a patch off.

Lockfile

Unchanged. pnpm install --frozen-lockfile passes against #198's lockfile as-is — warn means the runtime never becomes a dependency, so nothing to regenerate.

Note for reviewers

publish.yml loses registry-url / scope — pnpm/setup@v1 doesn't support them. That job publishes via OIDC provenance (id-token: write, no NODE_AUTH_TOKEN) to registry.npmjs.org, which is also pnpm's default, so it should be a no-op. It's the only change with external impact that CI can't exercise, so worth a second opinion before the next release.

Verification

Ran on pnpm 11.21.0 / Node 24.15.0 (darwin-arm64) against this branch rebased onto #198, all exit 0:

• pnpm install --frozen-lockfile (working tree stays clean afterward)
• pnpm build · pnpm typecheck · pnpm test · pnpm lint:check · pnpm fmt:check

The workflow changes themselves can only be proven by CI on this PR.

PR Checklist

• Is your PR title following our conventional commit naming recommendations?
• Have you filled in the PR Description Template?
• Is your branch up to date with the latest in main? — stacked on chore: add lefthook pre-commit hooks #198, not main
• Do the CI checks pass successfully?
• Have you smoke tested the example applications?
• Did you check that the changes meet accessibility standards? — N/A, no UI changes
• Have you tested the application on these browsers? — N/A, tooling-only change
  • Chrome (Fully supported)
  • Firefox (Major bug fixes supported)
  • Safari (Major bug fixes supported)

🤖 Generated with Claude Code