pnpm 11 Released — Pure ESM, Node 22+ Required, and 1-Day Release Cooldown On by Default (April 28, 2026)

The pnpm team on April 28, 2026 shipped pnpm 11.0.0 stable, the JavaScript package manager’s first major release in just over a year. The headline shift is security: minimumReleaseAge now defaults to 1 day, meaning newly published versions are simply not resolved until they have lived on the registry for 24 hours — a direct response to the Shai-Hulud npm supply-chain campaigns that compromised 492+ packages and 132 million monthly downloads in late 2025. The release also drops Node.js 18-21, distributes pnpm itself as pure ESM, replaces five build-allowlist settings with one, and switches the content-addressable store to a single SQLite-backed index.

What Happened

pnpm 11.0.0 was tagged at github.com/pnpm/pnpm/releases/tag/v11.0.0 at 09:48 UTC on April 28, 2026, after a beta cycle that started on March 26 and seven release candidates between April 10 and April 21. The official migration guide lives at pnpm.io/11.x/migration. According to the InfoQ writeup of the RC, this is the first pnpm major to break Node compatibility since v10 dropped Node 16 in early 2025.

The release lands in the long shadow of the Shai-Hulud 2.0 worm, which Wiz, Snyk and Palo Alto Unit 42 documented hitting the npm registry from September through November 2025 and again in early 2026 (covered separately on Doolpa as Bitwarden CLI Backdoored on npm). pnpm’s answer is to give compromised versions less time to spread.

Key Details

• Node.js 22+ required — pnpm dropped support for Node 18, 19, 20 and 21. The pnpm CLI itself is now distributed as pure ESM, and the standalone executable requires glibc 2.27 or later.
• minimumReleaseAge: 1440 on by default — newly published packages are not resolved by pnpm for 24 hours. Set minimumReleaseAge: 0 in pnpm-workspace.yaml to opt out.
• blockExoticSubdeps: true on by default — transitive dependencies pulled from git, tarball or http URLs are now blocked unless explicitly allowed.
• One allowBuilds setting replaces five — onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies and ignoreDepScripts are gone. strictDepBuilds is also true by default, so unknown postinstall scripts now hard-fail until you explicitly approve them.
• SQLite-backed store v11 — the content-addressable store now keeps package metadata in a single $STORE/index.db SQLite database (with WAL-mode concurrent reads and MessagePack values) instead of millions of small JSON files. Hex-only digests and bundled manifests cut the syscall count on installs.
• Native publish flow — pnpm publish, login, logout, view, deprecate, unpublish, dist-tag and version no longer shell out to the npm CLI. Remaining npm pass-throughs throw “not implemented”.
• Isolated global installs — pnpm add -g now creates a per-package directory under {pnpmHomeDir}/global/v11/{hash}/, each with its own package.json, node_modules and lockfile. Global packages can no longer break each other through peer-dep conflicts.
• New commands — pnpm ci, pnpm sbom, pnpm clean, pnpm peers check, pnpm runtime set, pnpm pack-app (Node SEA single-binary packager), pnpm with, plus short aliases pn and pnx.
• Audit endpoint changed — pnpm audit now uses npm’s bulk advisories API and GHSA identifiers; migrate auditConfig.ignoreCves entries to auditConfig.ignoreGhsas.
• .npmrc is auth/registry only — every other setting must move to pnpm-workspace.yaml or the new global config.yaml; environment variables now use the pnpm_config_* prefix.

What Developers and Users Are Saying

Reaction on Hacker News and Reddit is broadly positive but split on the cooldown default. The most-upvoted comments on the recurring “pnpm has a new setting to stave off supply chain attacks” threads frame minimumReleaseAge as the most important npm-ecosystem default change of the year, while critics argue, in one widely-shared comment, that “Delays in publishing not only slow down attacks, they also slow down critical security patches” and that maintainers who weren’t reviewing diffs before still won’t. Snyk’s SHA1-Hulud writeup in particular cited pnpm’s client-side controls as the model the rest of the npm ecosystem should adopt.

Among Postman’s engineering blog and the pnpm team’s own December 2025 newsroom security post, the framing is that npm is improving the publish side and pnpm is hardening the consume side. The combination of minimumReleaseAge, strictDepBuilds and blockExoticSubdeps is meant to make compromised packages unprofitable: by the time a worm spreads, the cooldown window has expired, the registry has yanked the version, and pnpm refuses to install it.

What This Means for Developers

If you upgrade today on a Node 22+ machine you should expect three categories of breakage. First, any package that runs a postinstall script will now fail until you list it under allowBuilds: { name: true } — this is the same trade-off pnpm 10 introduced with onlyBuiltDependencies, but the option name and shape have changed and the old keys silently no longer work. Second, fresh installs that target packages published in the last 24 hours will stall; CI pipelines that pin to latest on bleeding-edge libraries should either set minimumReleaseAge: 0 or pin specific versions. Third, any tooling that called pnpm to delegate to the npm CLI — common in monorepo publish scripts — needs auditing because pnpm 11’s native publish flow has slightly different semantics for tarball signing, OTP prompts and dist-tags.

For workspace authors the migration guide is short but unforgiving. .npmrc entries for caching, hoisting, side-effect cache, public-hoist patterns and a dozen other knobs must be moved to pnpm-workspace.yaml; auditConfig.ignoreCves must be rewritten as ignoreGhsas; and allowNonAppliedPatches is gone in favor of allowUnusedPatches.

What’s Next

The pnpm team has flagged a Rust rewrite of the package-manager core, tracked as the pacquet project, as the next major direction; pnpm 11’s SQLite store and undici-based HTTP layer are explicit setup steps for that handoff. The 11.x line will receive feature work; LTS for 10.x is expected to wind down once the 11.x release cadence settles, mirroring the v9 to v10 transition.

Sources

• pnpm 11.0.0 release notes on GitHub — primary source, full changelog and migration links
• InfoQ — pnpm 11 Release Candidate: ESM Distribution, Supply Chain Defaults and a New Store Format
• pnpm.io — Migration guide v10 → v11
• Wiz — Sha1-Hulud 2.0 Supply Chain Attack: 25K+ Repos Exposed
• Snyk — SHA1-Hulud npm Supply Chain Incident
• Hacker News — pnpm has a new setting to stave off supply chain attacks (discussion)
• pnpm blog — How We’re Protecting Our Newsroom from npm Supply Chain Attacks