pnpm 12 Is Now What You Install By Default

Rewrites are usually announced loudly and adopted quietly. This one has gone the other way. The pnpm 12 announcement was deliberately low-drama — "pnpm 12 is stable. It is a rewrite of pnpm in Rust. Upgrading should not feel like a migration" — and at that point it was opt-in, because the latest dist-tag still resolved to pnpm 11.

That has changed, and the change is the thing worth knowing. Nobody blogged a migration guide at you. The default just moved.

The dist-tag moved, and that is the actual news

Checked against the npm registry's dist-tags endpoint on 1 October 2026, pnpm's tags read: latest: 12.8.1, next: 12.8.2, latest-12: 12.8.1, latest-11: 11.28.2, next-11: 11.28.3.

Three consequences, in order of how likely they are to surprise you:

A fresh install on a new machine or a fresh CI image gets pnpm 12. Any packageManager field or setup step that resolves a range rather than an exact version can cross the major boundary on its own. And the existence of a maintained latest-11 tag means the project expects some people to stay — which is a more honest signal about rewrite maturity than any blog post.

If your pipeline pins an exact version, nothing happens to you today. If it does not, this is the same class of silent-default problem as the runner image moving underneath you, which we went through in ubuntu-latest moves to Ubuntu 26.

The two differences that break CI outright

pnpm documents eight behaviour differences between 11 and 12. Six are semantic and will change results. Two are hard rejections, and they are the ones to grep for before you upgrade anything.

1. pnpm install --resolution-only is gone. pnpm's own wording: "pnpm 12 does not implement this flag and rejects it." Not deprecated, not ignored — rejected. The documented replacement is pnpm peers check. If a peer-dependency validation job calls this flag, it fails immediately on upgrade.

2. --frozen-lockfile false no longer parses. "pnpm install --frozen-lockfile false is no longer supported." The space-separated boolean form is out; use --no-frozen-lockfile, or --frozen-lockfile with no argument. This one is nastier than it looks, because the old form appears constantly in CI templates where someone wanted to conditionally disable frozen installs by interpolating a variable.

Both are a two-minute grep across your workflow files. Do it before the dist-tag does it for you.

The six that change behaviour quietly

Area	pnpm 11	pnpm 12
Git dependencies	Could record [email protected]:owner/repo.git, "which then failed for everyone without a key"	A specifier "only says which repository you want, not how to reach it"
Cyclic graphs	"cut wherever it happened to walk in"	Breaks cycles "at a fixed place" — same edge regardless of entry point
Linux import method	auto was clone-first	auto "tries a hardlink before a reflink"
engineStrict	Installs and prints an install-check warning	Fails the install even through optional nesting
Tool names	pnpm add yarn installed the npm package	Records it in packageManager instead; -g node/deno installs real releases
Global bins	No equivalent	A global node/deno/bun "runs the version the current project pins"

The engineStrict change is the one to flag for a monorepo. A transitive package with a stale engines field that used to warn now fails the install, and the optional-dependency escape hatch no longer applies. That is a correctness improvement and a Monday-morning outage, depending on your tree.

The git-dependency change is unambiguously good. Lockfiles recording an SSH URL were unusable for anyone without a deploy key — a recurring source of "works on my machine" in CI. Making the specifier an identity rather than a transport is reason enough to move if you pull internal packages from git.

What the rewrite actually bought

pnpm publishes two concrete numbers rather than a headline multiplier, which is to its credit. Large workspaces with many cycles "resolve peers 2–3× faster and use about 25% less memory, and their lockfiles shrink." On btrfs, the hardlink-before-reflink change "roughly halves the time an install spends materializing node_modules from a warm store."

Both wins are conditional — many cycles, warm store, a specific filesystem. If you run a single small package on a cold CI cache, the rewrite is not going to show up in your build times, and you should upgrade for the behaviour fixes rather than the speed.

The more interesting capability is the one we covered separately: pnpm 12 resolves PyPI and crates.io packages alongside npm in the same workspace, which is the subject of pnpm 12.4: Python, Cargo and pipelines. That is a genuinely new thing for a JavaScript package manager to do, and it only exists on the 12 line.

Five weeks, eight minors, and four hardening fixes

Here is the cadence since stable, from pnpm's release blog: 12.0 on 26 August, 12.1 on 29 August, 12.2–12.3 on 2 September, 12.4 on 10 September, 12.5 on 18 September, 12.6 on 22 September, 12.7 on 25 September, and 12.8 after that. Eight minor releases in roughly five weeks.

Read the titles and the picture sharpens. The 12.2–12.3 post is described as "a long list of things pnpm 11 did that the Rust CLI did not, put back." That is the honest shape of a rewrite one week after it ships: feature parity is still being closed, in public.

And 12.7 carried four hardening fixes at once. Environment variables are no longer expanded in a userAgent set in a project's pnpm-workspace.yaml — before, "pnpm sent the variable's value to the configured registry." A dependency's bin named like a system utility "can no longer redirect a POSIX bin shim or the pnpm, pn, pnpx, and pnx launchers." A storeDir inside the workspace "could let lifecycle scripts of packages in the store run without allowBuilds approval." And packages that run a lifecycle script are no longer hard-linked into the virtual store, so "a build script can no longer rewrite the workspace source of an injected package."

Three of those four are lifecycle-script and bin-shim territory — exactly the surface we flagged as untouched by install delays in install cooldowns in npm, pnpm, Yarn and Bun. Cooldowns buy you time against a freshly published malicious version; they do nothing about what a script does once it runs. 12.7 is the other half of that problem being worked, and 12.8 continues it by warning when pnpm pack or pnpm publish would include .env files not listed in files.

None of this is a reason to avoid pnpm 12. It is a reason to be on a recent 12, not the first one.

pnpm 11 is not abandoned

The JavaScript CLI is still getting real work, not just security patches. pnpm 11.28 "brings a large batch of fixes from pnpm 12 to the JavaScript CLI: pnpm deploy, --filter, nodeLinker: hoisted, and custom modulesDir setups all behave better." 11.26 did the same a fortnight earlier.

So backporting runs both ways: parity gaps get filled in 12, fixes flow back to 11. No end-of-life date for the 11 line appears to be published, which makes "stay on 11 for now" supportable rather than a stall — but unbounded, and unbounded positions on a package manager expire without warning. Treat it as a quarter, not a year.

What to actually do this week

Pin an exact version in packageManager, not a range. This is the whole mitigation. A dist-tag that moves under a range is how a major arrives on a Tuesday with nobody's name on it.

Then grep your workflows for --resolution-only and --frozen-lockfile false, check whether any internal dependency is an SSH git URL, and run one install with engineStrict on a 12 build to see what now fails rather than warns. Note too that 12.7 auto-generates pnpm-workspace.yaml from package.json's workspaces field when no config file exists — a quick YAML to JSON pass is the cheapest way to diff what you think that file says against what it says.

To stay on the old line deliberately, install from latest-11 rather than pinning a patch you will never revisit — that way you keep receiving the backports. And if you are weighing the broader toolchain churn this autumn, the release-cadence shift in Node's annual release schedule is the other moving piece, alongside the registry-side changes in publishing without tokens.

---

FAQ

Does npm install -g pnpm now give me pnpm 12?

Yes. The registry's dist-tags endpoint reports latest: 12.8.1 as of 1 October 2026. When pnpm 12.0 shipped as stable the announcement noted that the latest tag still pointed at pnpm 11, so this moved at some point after 26 August. Check the endpoint yourself before relying on either answer — it is a live value.

How do I stay on pnpm 11?

Install from the latest-11 dist-tag, which currently resolves to 11.28.2. That keeps you receiving the backported fixes rather than freezing on a patch. Pin an exact version in the packageManager field if you need reproducibility rather than currency.

Which pnpm 12 changes will break my CI?

Two are hard rejections. pnpm install --resolution-only is not implemented and is rejected outright; use pnpm peers check instead. And pnpm install --frozen-lockfile false no longer parses; use --no-frozen-lockfile or --frozen-lockfile with no argument. A third candidate is engineStrict, which now fails an install where pnpm 11 printed a warning.

Is pnpm 12 faster?

Conditionally. pnpm reports that large workspaces with many cycles resolve peers 2–3x faster with about 25% less memory, and that on btrfs the new hardlink-first import method roughly halves the time an install spends materializing node_modules from a warm store. Small projects on cold caches should not expect a visible difference.

Is a five-week-old Rust rewrite safe for production?

It is being actively hardened, which is both the reassurance and the caveat. Eight minor releases shipped in five weeks, one of them explicitly putting back things pnpm 11 did that the Rust CLI did not, and 12.7 carried four separate hardening fixes around bin shims and lifecycle scripts. Run a recent 12 rather than an early one, and pin the exact version.

---

The rewrite was the announcement. The dist-tag move was the migration, and it did not come with a blog post.