pnpm 12 Was Rewritten in Rust and Promises Faster Installs in CI Without Changing the Workflow

pnpm released version 12, replacing its TypeScript and Node.js implementation with a native Rust rewrite. The move, according to InfoQ's report, was made on purpose so no one would have to relearn the tool: commands, flags, settings, lockfile format, and the node_modules layout from pnpm 11 remain the same. In other words, it's an engine swap without changing the steering wheel.

For those building software in Brazil who run pnpm in CI/CD pipelines, this is the point that matters: the speed gain arrives without a painful migration. But the text that follows separates what the source measures from what remains open.

Where the Gain Really Shows Up

The improvement is more pronounced when a cache or node_modules already exists. In pnpm's own benchmarks, a clean install of the file-heavy fixture dropped from 8.2 seconds in the previous implementation to 5 seconds with Rust. A repeated install with a warm cache, lockfile, and node_modules plunged from 472 milliseconds to 15 milliseconds.

| Scenario | Previous implementation | pnpm 12 (Rust) | |---|---|---| | Clean install (heavy fixture) | 8.2 s | 5 s | | Repeated install (warm cache) | 472 ms | 15 ms |

In practice, it's the second scenario that tends to dominate day-to-day work: incremental builds, CI jobs with restored cache, containers that reuse layers. That's where the difference stops being a mere detail.

Independent Test on a Large Monorepo

InfoQ cites a production test by Socket on Vercel's Turborepo workspace: 21 projects and 1,670 packages. The median install time reductions ranged between 64.4% and 90.5% across six different scenarios.

There's an important and honest caveat in the measurement itself: the native Corepack artifact got larger, which made the first cold startup 11.1% slower. In exchange, the cached startup improved by 74.7%. In other words, the native binary trades a one-time upfront cost for consistent gains afterward. For pipelines that rarely spin up from scratch and reuse the cache frequently, the trade-off tends to favor pnpm 12.

How to Install It and What's Not Yet Available

Installing the new version is done with:

pnpm self-update next-12

Pay attention to this operational detail: the npm latest tag still points to pnpm 11, and at launch, Homebrew, winget, Scoop, and Chocolatey didn't offer version 12. The installation guide also covers options via npm and via a standalone script, including installation without Node.js. For those automating runner provisioning, it's worth checking which channel pnpm arrives through before assuming latest is already 12.

The Breaking Change Most Likely to Catch You in CI

The migration is designed to be minimal, but there's one point that deserves a review before you ship: the removal of pnpm install --resolution-only, now replaced by pnpm peers check. If you have this command in any pipeline step, it will break. In addition:

• Git dependencies hosted on GitHub, GitLab, or Bitbucket now resolve through canonical HTTPS URLs; private SSH access must be configured via Git URL rewriting.
• On Linux, pnpm now tries hardlinks before reflinks.
• Unknown keys in pnpm-workspace.yaml are now reported instead of being silently ignored, which can turn an old typo into a visible error.

The compatibility guide is required reading before promoting this version to production.

What's New Beyond Speed

pnpm 12 also introduces project-aware global binaries: a globally installed Node.js, Deno, or Bun can follow the runtime pinned by the current project. pnpm can provision npm, Yarn, and Bun itself, including the package manager requested by a dependency hosted on Git.

In addition, deterministic cycle handling produces byte-for-byte identical lockfiles and, according to the release notes, makes peer resolution two to three times faster in workspaces with many cycles, using about 25% less memory. For large monorepos with circular dependencies, that's a concrete relief on runner resources.

What the Community Is Discussing

The reaction centered on native tooling performance and its trade-offs. Frontend engineer Dennis Morello described the release as a performance launch wearing a bigger version number, noting that the visible workflow remains familiar.

In a discussion covered by Socket, former npm CLI maintainer Darcy Clarke argued that keeping package managers in JavaScript makes it easier to improve shared internals. The response from pnpm maintainer Zoltan Kochan was direct:

It was faster to rewrite pnpm in Rust than to migrate to ESM.

>

-- Zoltan Kochan, pnpm maintainer

On Hacker News, one commenter argued that, for them, npm is still the best choice because it's stable and the default, avoiding the need to install another tool in CI. Others pushed back on security grounds: npm runs dependency lifecycle scripts by default, something that requires an explicit opt-out, which is why several have already migrated to pnpm.

What Remains Open

Against npm, Yarn, and Bun, pnpm continues to set itself apart through its content-addressable store, strict dependency layout, and now a native binary. Bun still publishes faster results in its own benchmark suite, but pnpm removed Bun and Yarn from its public comparison after benchmark harness issues made broad rankings unreliable. In other words: comparing speed across package managers remains contested ground, and the number that matters is the one from your own pipeline, with your cache and your monorepo.

For Brazilian teams already running pnpm, the reasonable path is to test next-12 on a CI branch, measure repeated installs with a warm cache, and check whether any step uses --resolution-only before promoting it.