Loading today’s stories
Build1 distinct publisher3 min readPublished
The Rust rewrite keeps pnpm 11's commands and lockfile, so adopting it costs little more than pulling from the next-12 tag, but the headline percentage describes a 1.5-second install and the cold case improved by about two thirds.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Here is what a pnpm install actually spends its time on: fetching metadata and tarballs, unpacking files, resolving the dependency graph, and linking packages into node_modules [6]. Under the old implementation every invocation also paid to start a JavaScript runtime and routed that filesystem work through Node [7]. pnpm 12 puts the hot path in a native binary and leaves the CLI, the configuration, the lockfile format and the content-addressable store sitting on top of it [5]. Existing scripts should largely carry over, and one set of documentation covers both versions [28].
The top of Vercel's range is the case where node_modules already exists: a median of 1.476 seconds with a warm store fell to 142 milliseconds, and 1.385 seconds with a cold store fell to 141 [9]. That is 1.334 seconds saved, about 90.4% [20][25]. The bottom of the range is the case with no store, no node_modules and lifecycle scripts enabled: 9.850 seconds down to 3.472 [10]. That is 6.378 seconds saved, about 64.8% [21][22]. The weakest percentage in the set returns roughly 4.8 times more wall clock time than the best one [26].
The mechanism behind that spread is dull. Percentage reduction is largest where the baseline is mostly fixed overhead, and an install against an existing tree is close to a no-op: check, exit. When the real work is near zero, interpreter startup is the entire bill, and deleting it reads as 90%.
For the number to transfer, your loop has to look like that loop. Vercel ran 20 measured runs per version on one Linux system against a workspace of 1,670 packages [8][11]. If your day is repeated installs against a tree that is already there, you inherit most of the 90%. If your pain is a cold runner, plan on the two-thirds end.
The cost shows up at bootstrap. The native Corepack artifact is 47.3 MB against 17.5 MB for pnpm 10.28 [12], which is 2.7 times the size and about 29.8 MB more to fetch [23]. Uncached Corepack startup is 11.1% slower as a result, while cached startup is 74.7% faster [12]. Thirty megabytes to buy back a second is an easy trade on a laptop and a less obvious one on a runner that downloads it fresh every job.
Treat the ranking claims separately. According to socket.dev, a dispute over flawed and outdated package manager benchmarks has complicated where pnpm now sits against Bun and other rivals [18], and an earlier version of pnpm's own benchmark page compared pnpm 12 with Bun and Yarn using August 14 results that predated several fixes [19]. The Vercel figures survive that because they are not a race: one machine, one workspace, two versions of the same tool [8][11].
The motive for the rewrite is on the record. Lead maintainer Zoltan Kochan framed the release as part of a broader migration of Node.js package managers to Rust [15], which already sits under SWC, Biome, Oxc, Rolldown and parts of Turbopack [14]. His blunter version: "It was faster to rewrite pnpm in Rust than to migrate to ESM," adding that he regretted moving pnpm 11 to ESM [17]. Darcy Clarke, formerly of the npm CLI, read the same trend as evidence of Node's own gaps, naming slow progress on single-executable applications and foreign-function interfaces, and argued that keeping package managers in JavaScript or TypeScript makes it easier for them to share and improve common internals [16]. Upgrade this week and you buy the install time with that maintenance argument attached.
Ranked by verification strength, evidence, and original report placement.
pnpm 12 is now stable, replacing the package manager's Node.js and TypeScript foundation with a Rust rewrite while preserving the commands, settings, and lockfile format used by pnpm 11.
As of publication, npm's latest tag still points to pnpm 11, so pnpm 12 must be installed from the next-12 tag.
Users on pnpm 11.10 or newer can switch with: pnpm self-update next-12.
pnpm 12 retains the existing CLI, configuration, lockfile format, and content-addressable store that lets projects share package files instead of keeping a separate copy per installation.
Package installation is dominated by fetching metadata and tarballs, unpacking files, resolving dependency graphs, and linking packages into node_modules.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
The npm audit that works because it never installs the package1 distinct publisher
build
The repo's own control run deleted the 5-10x WASM claim from vizcrush's launch copy1 distinct publisher
build
A four-app workspace is where pnpm's symlink store starts paying for its migration cost1 distinct publisher
build
A default that is not a guard: tinycolor2's palette functions never return on analogous(-1)1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Well-instrumented, singly sourced
Every figure here — the 64.4% to 90.5% band, the 47.3 MB artifact, the halved disk footprint — reaches us through one write-up of one upgrade. What lifts it above the usual speed post is that the baselines are printed next to the percentages, the run count and machine are stated, and six cache and lifecycle-script permutations are separated out instead of averaged. What holds it down is that no one has re-run any of it, and the sample is a single 1,670-package repository.
Stable, but you have to ask for it
Stable does not yet mean default: npm's latest tag still pointed at pnpm 11 when Socket published, so using pnpm 12 means naming the next-12 tag. On the demand side there is exactly one identified user, Vercel's own Turborepo workspace, and no download counts, CI telemetry or other deployments anywhere in this reporting.
90% of a second and a half
The number that travels is the case where node_modules already exists: 1.476 seconds becomes 142 milliseconds. Genuine, pleasant in a watch loop, and worth 1.33 seconds. The case that actually costs you — cold store, nothing installed, lifecycle scripts running — improves by about 65% and gives back 6.4 seconds, roughly five times more wall clock than the headline case. The overstatement lives in the framing rather than the reporting: Socket prints the baseline, and pnpm has already retreated from claiming it is the fastest package manager.
The stopwatch belonged to interested parties
Vercel benchmarked its own monorepo; pnpm's maintainers ran the harness that turned out to be reusing metadata during supposedly clean installs and handing Bun a warm cache while pnpm ran cold. Socket, meanwhile, sells supply-chain security around the install step, which is why the piece keeps drifting toward stores, global bins and reproducibility. None of that is disqualifying — the corrections are on the record and the withdrawal of the Bun and Yarn comparison cuts against interest — but no disinterested party timed anything in this story.
Firm on pnpm versus pnpm, void on rankings
Split the story in two and the answers differ. That pnpm 12 is much faster than pnpm 10.28 on this repository is nailed down, with baselines, run counts and hardware stated, and the compatibility promise is the sturdiest thing in the reporting — same CLI, same config, same lockfile, same docs. Where pnpm stands against Bun is currently unknowable, and pnpm says as much. Read the compatibility path as reliable, the repo-specific numbers as plausible but unreplicated, and any ranking as withdrawn.