pnpm, the fast and disk efficient JavaScript package manager has released pnpm 11 RC, shipping a major rework that spans performance, supply chain safety, and a smaller, stricter configuration surface.
pnpm 11 RC introduces a new SQLite-backed store index, on by default supply chain protections, isolated global installs via the global virtual store, a unified allowBuilds setting, and a set of new commands including pnpm ci, pnpm sbom, pnpm clean, pnpm peers check, and pnpm runtime set, along with short pn and pnx aliases.
One of the headline changes is that pnpm is now distributed as pure ESM and requires Node.js v22 or later, with support for Node.js 18, 19, 20, and 21 dropped entirely. A compatibility matrix lives in the updated installation docs.
Security defaults are have been tightened, the minimumReleaseAge setting now defaults to 1 day, meaning newly published versions are not resolved for 24 hours, and blockExoticSubdeps defaults to true. This follows months of high profile supply chain incidents in the npm ecosystem, and drew discussion on Hacker News where commenters debated whether a grace period would meaningfully help detection.
Build script settings have been consolidated, onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies, and ignoreDepScripts have been removed in favour of a single allowBuilds option, and strictDepBuilds is now true by default. pnpm also stops reading configuration from the "pnpm" field of package.json and from npm_config_ environment variables, the global configuration file has moved to YAML, and allowNonAppliedPatches, ignorePatchFailures, pnpm server, and useNodeVersion are gone.
Global installs are now properly isolated, each pnpm add -g package receiving its own directory, package.json, node_modules, and lockfile, and the global virtual store is enabled by default for pnpm dlx and global packages, although it remains opt in for regular projects. Performance work includes a move to undici with Happy Eyeballs for HTTP, direct to store writes that skip the staging directory, pre-allocated tarball downloads, and an NDJSON metadata cache.
Developers can try the release today with:
pnpm self-update next-11
Migration guidance lives in the pnpm 11.x docs and the v11 tracking discussion.
On Hacker News, one commenter recommended pnpm over npm outright on a thread about recent security vulnerabilities, stating that "PNPM 10.x shutdown a lot of these attack vectors" and "NPM is too insecure for production CLI usage", though others pushed back, arguing that "NPM was never too insecure and remains not too insecure today".
The minimumReleaseAge default has been a particular focal point, also being referred to as 'dependency cooldowns'. A Hacker News thread on dependency cooldowns drew further debate around the topic, with one commenter noting that:
The people who will benefit from a cooldown weren’t reviewing updates anyway. Without the cooldown they would just be one more malware victim
While other commenters warned:
There's no free lunch here. Delays in publishing not only slow down attacks, they also slow down critical security patches. There's no one-size-fits-all policy here, you're at risk either way.
Compared to npm and Yarn, pnpm 11 retains its long standing advantages, isolated node_modules by default, content addressable storage, and first class monorepo support, while extending its lead on security with SBOM generation via pnpm sbom and stricter build script handling, areas where Yarn still lacks parity.
pnpm is an open source JavaScript package manager known for fast installs and efficient disk usage via a content addressable store and symlinked node_modules. It is widely used across frontend and backend ecosystems, and competes directly with npm, Yarn, and Bun.