Upgrade packageManager from pnpm 7 → pnpm 11 for supply-chain security defaults

[goldjohn6]

Context

The repo currently pins pnpm@7.33.7 in package.json (released August 2023, ~2 years old). pnpm has shipped four major versions since with security defaults specifically aimed at the npm supply-chain attack pattern that's been escalating through 2025–2026.

The Mini Shai-Hulud wave on 2026-05-11 compromised 84 artifacts across @tanstack/, @mistralai/, @squawk/, @uipath/, and others — 172 unique packages / 403 malicious versions in a 48-hour window. It was the first documented npm worm to produce malicious packages with valid SLSA Build Level 3 attestations, so signature-checking alone didn't catch it. Detection relied largely on the community spotting and yanking bad versions within hours of publication.

What pnpm 11 gives us

Three relevant defaults this repo currently doesn't have:

Default	Introduced	What it does
minimumReleaseAge: 1440 (24h)	pnpm 11 default	Refuses to install any version less than 1 day old. Filters out smash-and-grab attacks that get yanked within hours.
Postinstall script blocking via allowBuilds	pnpm 10 default	Postinstall scripts only run for explicitly allowlisted deps. Closes the most common malware execution path.
blockExoticSubdeps	pnpm 11 (opt-in)	Refuses transitive deps from git URLs / tarballs.

Risk for this repo specifically

Probably moderate, not severe:

• The publish workflows already use OIDC trusted publishing and trigger on workflow_dispatch only (not pull_request_target), so they're not exposed to the cache-poisoning vector Mini Shai-Hulud used.
• The exposure is on the install side: pnpm install on pnpm 7 has zero release-age protection. A future compromised transitive dep gets pulled straight in.
• powergrid-engine / powergrid-viewer aren't widely-depended-on, so downstream blast radius from a compromised publish is small.

What this would actually take

The trade-off already noted in the .github/workflows/engine-publish.yml comment around the npx -y pnpm@latest publish line is the real issue: bumping packageManager forces a lockfile rewrite. Both engine/pnpm-lock.yaml and viewer/pnpm-lock.yaml would regenerate with the pnpm 9+ lockfile format, which means transitive resolution can change. That needs a careful review pass with the test suite running on the new lockfile.

Worth noting the publish workflows already side-step the pin by running npx -y pnpm@latest publish ... — so modern pnpm is already in the publish path, just not in the install/test path.

There's also a stale shared-workspace-lockfile config warning surfacing on recent npm/pnpm versions that probably wants cleanup in the same pass.

Suggested approach

Happy to put up a PR if helpful — would look something like:

1. Bump packageManager to a current pnpm 11.x.
2. Run pnpm install to regenerate both lockfiles.
3. Verify CI test suites pass on the new lockfiles.
4. Optionally bump test workflow node-version from 14 → 22 to match the prettier workflow (pnpm 11 may require Node 18+ anyway).
5. Address the shared-workspace-lockfile config warning.

Lower priority, but worth doing before the next major wave.

References

• pnpm 11 supply-chain defaults (Socket)
• pnpm supply chain security docs
• Mini Shai-Hulud writeup (Wiz)