chore: upgrade pnpm 9 → 11 with supply-chain protection

[cameronapak]

RELATES TO https://lifechurch.atlassian.net/browse/YPE-2688

The recent news of seeing more and more supply-chain attacks via npm has caused me to want to make sure we're as secure as can be. That's what this PR does.

Summary

• Upgrade pnpm 9.0.0 → 11.10.0 with minimumReleaseAge: 4320 (3-day cooldown) to mitigate supply-chain attacks on new package versions
• Move overrides from package.json → pnpm-workspace.yaml (pnpm 11 breaking change — overrides in package.json no longer enforce for auto-installed peers)
• Pin every override to an exact version — vite was the last loose range (>=5.4.21 → 7.3.3), which could otherwise resolve a compromised newer release silently
• Remove version pins from all CI workflows — pnpm/action-setup@v4 now reads from packageManager field (single source of truth)

Changes

File	Change
package.json	packageManager: "pnpm@11.10.0", engines.pnpm: ">=11.0.0", removed pnpm.overrides, added @internal/eslint-config + eslint-plugin-storybook as root devDeps
pnpm-workspace.yaml	Added minimumReleaseAge, exact-pinned overrides (incl. vite: "7.3.3"), allowBuilds (@swc/core: false — tsup uses esbuild, swc native build unneeded)
CONTRIBUTING.md	Prerequisites bumped to Node >=22, pnpm >=11 to match engines
.github/workflows/ci.yml	Removed 4x version: 9.0.0 pins
.github/workflows/release.yml	Removed version: 9.0.0 pin
.github/workflows/storybook.yml	Removed version: 9.0.0 pin
AGENTS.md	Updated pnpm version refs, added supply-chain protection docs

pnpm 11 breaking changes handled

• Overrides must live in pnpm-workspace.yaml (not package.json) to enforce for auto-installed peers
• Build scripts require allowBuilds approval (esbuild, @parcel/watcher, msw)
• Workspace packages not hoisted to root — @internal/eslint-config and eslint-plugin-storybook must be root devDependencies
• minimumReleaseAge blocks packages published < 3 days ago; override with --force if needed urgently

Verification

• pnpm lint — all 7 packages pass
• pnpm typecheck — all 6 packages pass
• pnpm test — 751 tests pass (core: 298, hooks: 275, ui: 178)

Greptile Summary

This PR upgrades the workspace to pnpm 11 and adds supply-chain install protections. The main changes are:

• pnpm is pinned through packageManager at 11.10.0.
• Node and pnpm requirements are raised in package metadata and docs.
• pnpm settings and overrides move into pnpm-workspace.yaml.
• minimumReleaseAge and exact dependency overrides are added.
• CI workflows now let pnpm/action-setup read the package manager version.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
package.json	Updates the workspace package manager, engine requirements, and root dev dependencies for pnpm 11.
pnpm-workspace.yaml	Adds workspace-level pnpm settings, exact overrides, release-age protection, and build-script approvals.
.github/workflows/ci.yml	Updates CI to use Node 22 and package-manager-driven pnpm setup.
.github/workflows/storybook.yml	Updates Storybook CI to use Node 22 and package-manager-driven pnpm setup.
.github/workflows/release.yml	Removes the hardcoded pnpm setup version and keeps the release workflow on Node 24.

Comments Outside Diff (1)

1. pnpm-lock.yaml, line 194-195 (link)

   @swc/core no longer resolved as a tsup peer

   Across every package (root, packages/core, packages/hooks, packages/ui), tsup@8.5.0 previously resolved with @swc/core@1.13.5 as a satisfied peer; after this upgrade it resolves without it. This means tsup will now use esbuild as its transformer instead of SWC. If any package's tsup.config.ts explicitly sets esbuildOptions or SWC-specific options, behaviour changes silently. The test suite passing is reassuring, but it's worth confirming no tsup.config references experimentalDts or similar options that behaved differently under SWC.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: pnpm-lock.yaml
   Line: 194-195
   
   Comment:
   **`@swc/core` no longer resolved as a `tsup` peer**
   
   Across every package (`root`, `packages/core`, `packages/hooks`, `packages/ui`), `tsup@8.5.0` previously resolved with `@swc/core@1.13.5` as a satisfied peer; after this upgrade it resolves without it. This means tsup will now use esbuild as its transformer instead of SWC. If any package's `tsup.config.ts` explicitly sets esbuildOptions or SWC-specific options, behaviour changes silently. The test suite passing is reassuring, but it's worth confirming no `tsup.config` references `experimentalDts` or similar options that behaved differently under SWC.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

_{Reviews (10): Last reviewed commit: "Merge branch 'main' into chore/pnpm-11-u..." | Re-trigger Greptile}

Context used (4)

• Context used - CLAUDE.md (source)
• Context used - AGENTS.md (source)
• File used - docs/review-guidelines.md (source)
• Context used - Enforce project-specific review guidelines - see d... (source)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4941855

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cameronapak]

Hey @jhampton, Can I get your feedback on this PR? Mainly around the idea of it. I just want to make sure that with the rise of supply chain attacks, that we are protected on our repos. So I just want to share this with you and let me know so that I can hear your feedback (any feedback)

[cameronapak]

CLAUDITHAN SAYS

Re: the Greptile note that @swc/core is "no longer resolved as a tsup peer" (pnpm-lock.yaml 194-195) — Cam asked me to verify it. It doesn't hold, on two counts:

1. Stale premise. After the lockfile regen on the current head, @swc/core@1.13.5 is resolved as a tsup peer across all four packages:

pnpm-lock.yaml:59,175,221,366
  tsup@8.5.0(...)(@swc/core@1.13.5(@swc/helpers@0.5.17))(...)

Greptile reviewed an earlier commit where swc had transiently dropped out; the regen restored it, so "resolves without it" no longer describes this code.

2. Wrong mechanism regardless. tsup always transforms/bundles with esbuild. @swc/core is an optional peer used for exactly one thing — emitting legacy decorator metadata (emitDecoratorMetadata). This repo uses no decorators (grep emitDecoratorMetadata / experimentalDecorators → 0 hits), so swc is never on the code path whether installed or not. The experimentalDts concern also doesn't apply: the tsup config sets dts: false (types come from tsc + API Extractor).

Net: nothing to fix. The green build is expected, not just reassuring — esbuild was always the transformer. (Also FYI: allowBuilds: @swc/core: false only skips the native binary's postinstall; harmless here since nothing invokes swc.)