chore: upgrade to pnpm 12 and restore Node 20 in CI

[dinwwwh]

Moves the workspace from pnpm 11 to pnpm 12 and puts Node 20 back into the CI test matrix. pnpm 12 verifies every lockfile entry against its supply-chain policies before installing, and that pass looks @jsr/* packages up on the default npm registry, which 404s and aborts every install. The JSR scope is now declared through the registries setting in pnpm-workspace.yaml, so the existing jsr: specifiers keep working unchanged.

Changes

• devEngines.packageManager requires pnpm ^12.0.0; the lockfile records pnpm 12.3.4 as the self-provisioned package manager. pnpm/action-setup reads the same field, so CI needs no workflow change for it.
• registries maps the @jsr scope to https://npm.jsr.io/, the registry the jsr: protocol already resolves through internally. Without it pnpm 12 fails with ERR_PNPM_META_FETCH_FAIL on @jsr/std__assert before fetching anything. pnpm 12 rejects the .npmrc-style @jsr:registry key in the workspace file as unrecognized, so this is the supported workspace form.
• Node 20 is back in the CI matrix. It was dropped because pnpm 11 required Node 22.13; pnpm 12 runs on Node 18 and up.
• Transitive dependencies refreshed within their existing ranges (eslint plugins, postcss, browserslist data).

Testing

• pnpm install with pnpm 12.3.4 from an empty node_modules passes the supply-chain check and installs 735 packages; --frozen-lockfile is clean afterwards.
• Full suite on Node 20.20.2 via pnpm runtime set node 20, the same way the CI job runs it: vitest 1082 tests in 59 files, Bun 50 tests, Deno 4 suites with 50 steps, all passing. Same result on Node 24.20.0.
• pnpm run lint and pnpm run type:check pass.

[pkg-pr-new]

• @standardserver/hono-node-playground
• @standardserver/node-http-playground

@standardserver/aws-lambda

npm i https://pkg.pr.new/@standardserver/aws-lambda@86

@standardserver/core

npm i https://pkg.pr.new/@standardserver/core@86

@standardserver/fastify

npm i https://pkg.pr.new/@standardserver/fastify@86

@standardserver/fetch

npm i https://pkg.pr.new/@standardserver/fetch@86

@standardserver/node

npm i https://pkg.pr.new/@standardserver/node@86

@standardserver/peer

npm i https://pkg.pr.new/@standardserver/peer@86

@standardserver/shared

npm i https://pkg.pr.new/@standardserver/shared@86

commit: 71bc2c8

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 108 skipped benchmarks¹

---

_{Comparing claude/pnpm-12-jsr-urls-1cb7a7 (71bc2c8) with main (63c66ad)}

Footnotes

1. 108 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[pullfrog]

✅ No new issues found.

Reviewed changes — Tooling/CI chore: devEngines.packageManager moved from pnpm ^11 to ^12, the lockfile re-provisions pnpm 12.3.4 in self-executable form (dropping the old @pnpm/exe/@reflink dependency pair), pnpm-workspace.yaml gains a registries route mapping the @jsr scope to https://npm.jsr.io/ so pnpm 12's lockfile supply-chain verification can re-resolve the jsr:-protocol packages, Node 20 is restored to the test matrix, and a few transitive deps (eslint-plugin-jsdoc, eslint-plugin-regexp, @eslint/plugin-kit, postcss, browserslist data) are refreshed within their existing ranges.

I verified the two load-bearing claims directly on pnpm 12.3.4: pnpm i --frozen-lockfile passes the supply-chain check over all 835 lockfile entries, and a fresh pnpm i from an empty node_modules resolves the @jsr specifiers without ERR_PNPM_META_FETCH_FAIL — neither run rewrites the lockfile. The registries shape matches pnpm's documented URL-keyed form, and pnpm/action-setup@v6 does read devEngines.packageManager, so the "no workflow change needed" claim holds.

ℹ️ Node 20 is EOL

Node 20 hit end-of-life on 2026-04-30, so this restores an unsupported runtime to the matrix. Keeping it is defensible — consumers running the library on Node 20 are precisely who gain coverage — but the PR's stated rationale is "unblocked by pnpm 12", not "Node 20 is a supported target", and no workspace package declares an engines field to pin a support contract. If broader old-runtime coverage is the goal, pnpm 12 (engines >=18.*) also enables a Node 18 leg.

Technical details

# Consider the EOL Node 20 matrix leg

## Context
- `.github/workflows/ci.yaml:30` — `node-version: [26, 24, 22, 20]`.
- Node 20 maintenance LTS ended 2026-04-30; no security fixes thereafter.
- No `engines` field in root `package.json` or any workspace package.

## Open questions for the human
- Keep the Node 20 leg for downstream-compat confidence, or use the slot for Node 18 (now supported by pnpm 12)?

  ^{｜ View workflow run ｜ Using DeepSeek Flash (default — pick a model for stronger reviews) ｜ 𝕏}