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 monorepo from pnpm 9 to pnpm 11.10.0 and adds supply-chain protections, handling all pnpm 11 breaking changes along the way.

• pnpm 11 migration: Overrides moved from package.json → pnpm-workspace.yaml (required for peer enforcement), .npmrc stripped to auth/registry only, allowBuilds map replaces the legacy onlyBuiltDependencies/neverBuiltDependencies settings, and @internal/eslint-config + eslint-plugin-storybook added as explicit root devDependencies to compensate for the removed workspace hoisting.
• Supply-chain hardening: minimumReleaseAge: 4320 (3-day cooldown, in minutes) blocks packages published less than 72 hours ago from being resolved; vite override tightened from a loose >=5.4.21 range to the exact 7.3.3; all CI workflows now derive the pnpm version from the packageManager field rather than hardcoded pins.
• Node / CI bump: engines.node raised to >=22.13.0, Node in all CI jobs bumped to 24, consistent with the documented pnpm 11 minimum and what AGENTS.md/CONTRIBUTING.md now state.

Confidence Score: 5/5

Safe to merge — all pnpm 11 breaking changes are handled correctly, the supply-chain settings are well-configured, and the previous concerns about engines.node floor and minimumReleaseAgeExclude have both been resolved in the final state of the diff.

This is a carefully executed tooling upgrade. The overrides migration, allowBuilds map, .npmrc cleanup, and packageManager hash are all structurally correct per the pnpm 11 docs. The engines.node floor matches AGENTS.md/CONTRIBUTING.md/review-guidelines.md (>=22.13.0). The minimumReleaseAge value of 4320 is in minutes (confirmed), giving the documented 3-day cooldown. All CI workflows consistently derive the pnpm version from the packageManager field. The 751-test suite passing gives further confidence that the esbuild-only tsup path (with @swc/core build suppressed) works correctly.

No files require special attention.

Important Files Changed

Filename	Overview
pnpm-workspace.yaml	New central config hub for pnpm 11: minimumReleaseAge (4320 min = 3 days), migrated .npmrc hoisting settings, exact-pinned overrides, and allowBuilds map — all correct per pnpm 11 docs
package.json	packageManager bumped to pnpm@11.10.0 with SHA-512 integrity hash; engines.node raised to >=22.13.0 matching docs; pnpm.overrides block removed (moved to pnpm-workspace.yaml)
.npmrc	Correctly stripped to a comment-only file; all non-auth/registry settings migrated to pnpm-workspace.yaml per pnpm 11 requirements
.github/workflows/ci.yml	Dropped hardcoded version: 9.0.0 from pnpm/action-setup@v4 (now reads packageManager field); Node bumped 20→24 across all 4 jobs
.github/workflows/release.yml	Removed pnpm version pin; now relies on packageManager field for version resolution
.github/workflows/storybook.yml	Removed pnpm version pin and bumped Node 20→24; consistent with other workflow changes
AGENTS.md	Updated Node/pnpm prerequisites to 22.13.0/11.0.0; added supply-chain protection docs and pnpm 11 breaking-change notes for agent guidance
pnpm-lock.yaml	Lock file regenerated for pnpm 11; vite overridden to exact 7.3.3, @swc/core no longer resolved as a tsup peer (expected — allowBuilds disables its build script)

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[pnpm install] --> B{Lockfile frozen?}
    B -- Yes / CI --> C[Install from lockfile\nno resolution step]
    B -- No / local add --> D{minimumReleaseAge\n4320 min = 3 days}
    D -- Package age < 3 days --> E[❌ Blocked\nuse --force to override]
    D -- Package age ≥ 3 days --> F{In allowBuilds?}
    F -- Not listed --> G[Install, no build script run]
    F -- Listed: true --> H[Install + run build script\ne.g. esbuild, msw, @parcel/watcher]
    F -- Listed: false --> I[Install only\nbuild script suppressed\ne.g. @swc/core]
    C --> J[✅ Packages installed]
    G --> J
    H --> J
    I --> J

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[pnpm install] --> B{Lockfile frozen?}
    B -- Yes / CI --> C[Install from lockfile\nno resolution step]
    B -- No / local add --> D{minimumReleaseAge\n4320 min = 3 days}
    D -- Package age < 3 days --> E[❌ Blocked\nuse --force to override]
    D -- Package age ≥ 3 days --> F{In allowBuilds?}
    F -- Not listed --> G[Install, no build script run]
    F -- Listed: true --> H[Install + run build script\ne.g. esbuild, msw, @parcel/watcher]
    F -- Listed: false --> I[Install only\nbuild script suppressed\ne.g. @swc/core]
    C --> J[✅ Packages installed]
    G --> J
    H --> J
    I --> J

Loading

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 (17): Last reviewed commit: "docs: state Node 22.13 minimum with Node..." | Re-trigger Greptile}

[changeset-bot]

⚠️ No Changeset found

Latest commit: e96ac7e

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.)

[bmanquen]

Just a couple of questions for clarity, both non blocking.

[cameronapak]

Tests are failing due to: https://appwrite.io/blog/post/nodejs-v25-whats-new#the-localstorage-controversy

[Dustin-Kelley]

LGTM!