pnpm 11 ships with supply-chain defaults turned on as the JavaScript ecosystem digests Shai-Hulud
minimumReleaseAge=1d, blockExoticSubdeps=true, strictDepBuilds=true — three settings that existed in pnpm 10 and were off until this release.
The release ships three settings that already existed and flips them all on. pnpm 11 reached release-candidate on April 21, and the substantive change is not the SQLite-backed store, the move to pure ESM, or the Node 22 floor. It is that minimumReleaseAge now defaults to one day, blockExoticSubdeps defaults to true, and strictDepBuilds defaults to true — three knobs available in pnpm 10 and each turned off until this release. A package manager used by a meaningful share of the JavaScript ecosystem has, in a single version bump, raised its trust posture by three notches the post-Shai-Hulud discourse has been arguing for since March.
Each default targets a different attack surface. minimumReleaseAge=1d makes a freshly published version ineligible for resolution for twenty-four hours, which is the empirical window in which the npm advisory pipeline usually catches a malicious release; the Shai-Hulud worm earlier this month and the Axios incident in March both surfaced inside that window. blockExoticSubdeps refuses transitive dependenciesSecondary software packages that are installed automatically because a primary dependency requires them, forming deep, often unreviewed trees of third-party code. expressed as git URLs, file paths, or other non-registry sources — closing the path by which a clean direct dependency drags in something a lockfileA generated file that records the exact version of every direct and transitive dependency installed in a project, ensuring builds are reproducible across different machines. review never had a chance to examine. strictDepBuilds refuses to silently swallow a transitive postinstall failure, and the five legacy build-script flags collapse into a single allowBuilds map demanding per-package approval.
The winners are the security teams that have been writing internal pnpm-config patches to enforce these exact defaults for the last eighteen months; their patches are now upstream. The losers are the medium-sized monoreposA software architecture where multiple distinct projects or components are stored in a single version-control repository, typically sharing dependencies and build tooling. that depend, often without knowing, on git-URL subdeps or intermittent postinstall scripts — those repositories will see lockfileA generated file that records the exact version of every direct and transitive dependency installed in a project, ensuring builds are reproducible across different machines. diffs and build failures on the first pnpm 11 install, and the discovery will be retroactive triage rather than planned migration. The Node 22 minimum also cuts off CI runners still on 20.
The release also repositions pnpm against npm and yarn, neither of which ships these defaults at the registry-resolution layer. npm has minimumReleaseAge as opt-in; yarn's equivalent lives behind a plugin. Any ecosystem-level argument about trust defaults now has a working reference implementation it did not have last week, which changes the burden of proof for the other two managers. New pnpm sbom and pnpm peers check commands give CI pipelines a registry-native way to enumerate what they are about to install.
What pnpm 11 forecloses is the position that supply-chain hygiene is necessarily a downstream concern — bolted on by GitHub Advanced Security, Snyk, Socket, or an internal proxy. The defaults now live in the resolver. What it opens is the governance question of whose defaults a package manager is allowed to ship: a one-day release-age threshold is a normative claim about how fast software should move, and the projects that need same-day resolution will spend the next six months tuning around it.