get-pnpm moves from pnpm/get.pnpm.io into pnpm/npm/get-pnpm, at 0.0.9
(get.pnpm.io be4e983, where its history stays).
- The pnpm v12 npm package depends on it with `workspace:*`, so a pnpm
release bundles get-pnpm's source as of that release. A wrapper fix no
longer needs a get-pnpm release, a catalog bump, and a
minimumReleaseAge exclusion first. bundle-node-gyp builds it before
the deploy injects its build output.
- It is released on its own: a `get-pnpm` product in bump.ts and
create-release-pr.yml (off by default), `get-pnpm@<version>` tags,
and build-get-pnpm/publish-get-pnpm jobs in release.yml. It is private
in the workspace so the TypeScript release's recursive publish skips
it; the packed manifest drops the flag.
- Its runtime dependencies stay exact, through a `get-pnpm` named
catalog. Its lint is the root ESLint config. Its TLS tests use the
fixture the Rust network tests use.
- The npm-wrapper CI job runs its tests on Node.js 24 and 22, beside
the wrapper's. The forwarding proxy in its download tests forwards
only to the servers the tests start.
npm's registry signing keys were pinned in five places: v11, v12,
get-pnpm, and get.pnpm.io's install.sh and install.ps1. Only v11's copy
was refreshed, by the release PR, and the two repositories handled a
withdrawn key in opposite ways. They now come from
.config/npm-signing-keys.json:
- .github/scripts/update-npm-signing-keys.mjs refreshes it from npm on
every release PR, not only v11 ones. A key npm stops listing stays,
marked withdrawn.
- The meta-updater renders it into the v11, v12, and get-pnpm copies,
so `pnpm lint:meta` fails on a copy edited by hand. pnpm v11 and v12
keep trusting withdrawn keys, so packages signed before a rotation
verify. get-pnpm drops them, as get.pnpm.io's installers do.
- get.pnpm.io's update script is to read this file.
Zoltan Kochan
1860c1c75e