chore: migrate from yarn 1 to pnpm with supply chain hardening

[Kabidoye-17]

Why?

yarn 1 is unmaintained. Migrating to pnpm 10 provides a stricter dependency graph (which surfaced a phantom devDep in this repo — tslib) and unlocks pnpm-native supply-chain controls (minimumReleaseAge, trustPolicy: no-downgrade).

How?

• Convert the lockfile in place. pnpm import translates yarn.lock → pnpm-lock.yaml verbatim; no version drift. yarn.lock is deleted; packageManager: pnpm@10.23.0+sha512.… pins the manager for corepack with an integrity hash, so any tarball that doesn't hash-match is refused.
• Migrate resolution config. resolutions moves to pnpm.overrides. husky goes to ignoredBuiltDependencies — its install script only sets up local git hooks, so blocking it in CI is safe.
• Add pnpm-workspace.yaml with minimumReleaseAge: 10080 (refuse to resolve versions less than 7 days old) and trustPolicy: no-downgrade (refuse a package whose provenance is weaker than what's currently locked).
• Declare tslib explicitly. Previously a phantom devDep silently satisfied by yarn 1's flat hoisting; rollup-plugin-typescript2 needs it at build time.
• CircleCI: bump image circleci/node:12.21 → cimg/node:22.14.0 (pnpm 10+ requires Node 20+; matches .nvmrc), corepack bootstrap (with sudo for the non-root executor), cache key keyed on pnpm-lock.yaml. Also raises Node's old-space size to 4 GB for test:ci — Node 22's stricter heap accounting exposed an OOM on the coverage-instrumented render.test.ts worker that Node 12 tolerated.
• Publish workflow: add pnpm/action-setup@v4.1.0 (SHA-pinned) and swap yarn install / yarn build for the pnpm equivalents. All existing hardening (SHA-pinned actions, persist-credentials: false, env-routed ${{ }}, explicit permissions:) preserved.
• Docs: CONTRIBUTING.md moves contributors to pnpm (contributors work inside this repo, where pnpm is enforced). README.md's consumer-install snippet lists npm, yarn, and pnpm side by side — this is a published library, and we deliberately don't want to constrain consuming apps to any one package manager. Every JS package manager reads the same package.json, so the installed result is identical regardless of which command a consumer runs; documenting all three removes the mental translation step and avoids implying an opinion we don't have.

Contributor-flow change: local git hooks (via husky) no longer install automatically on pnpm install — a contributor who wants them runs pnpm rebuild husky once. This is deliberate: the alternative (adding husky to onlyBuiltDependencies) executes its install script on every install, including in CI where hooks are meaningless.

_{Generated with Claude Code}

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​tslib@​2.8.1
	github/​pnpm/​action-setup@​7088e561eb65bb68695d245aa206f005ef30921d

View full report

[Kabidoye-17]

Local verification

Evidence from local testing of this branch before opening the PR.

Test suite on the branch — 24 suites / 55 tests / 47 snapshots green:

Tarball manifest from pnpm pack — only dist/**, package.json, README.md, and LICENSE.md ship to consumers (no src/, no tests, no config):

Consumer install via npm — the branch tarball installed into a scratch project + --help renders correctly:

Consumer install via pnpm — same tarball, same result:

Because --help renders end-to-end from the tarball, the compiled dist/ is transitively proven to build and load correctly under both managers.

A note on yarn 1: the same tarball installs fine for consumers on yarn — a smoke-test attempt on my laptop failed for a local-machine reason (unmaintained yarn 1 + corporate SSL proxy + Node 22 don't play well together), not a package or migration issue. The tarball is byte-for-byte the same one npm and pnpm above installed without incident.

What CI now covers (for reviewers)

The updated CircleCI pipeline (cimg/node:22.14.0, medium executor) runs on every push and is the authoritative continuous check. A green run means all of the following are verified:

1. corepack enable && corepack prepare --activate — resolves and verifies the pinned packageManager (pnpm@10.23.0+sha512.…); any pnpm tarball that doesn't hash-match is refused.
2. Registry routing check — asserts pnpm's active registry is routed through the corporate proxy, not the public one.
3. pnpm install --frozen-lockfile — enforces pnpm-lock.yaml matches package.json byte-for-byte; also exercises trustPolicy: no-downgrade and minimumReleaseAge: 10080 against the locked graph on every push.
4. pnpm run format:check — prettier clean.
5. pnpm run lint — tslint clean.
6. pnpm run test:ci — full jest suite, now with NODE_OPTIONS=--max-old-space-size=4096 to accommodate Node 22's stricter heap accounting on the coverage-instrumented render.test.ts worker.

Between the local checks above (build + tarball + consumer install + CLI runtime) and CI (install + supply-chain enforcement + lint + format + tests), every stage of the release path is covered.

~ Automated via Claude