pnpm 12 Released, Up to 90% Faster with Rust Rewrite
pnpm 12 released with Rust rewrite. It keeps full compatibility while cutting install times by up to 90%, plus a new dedicated registry server pnpr.
Version 12 of pnpm, the package manager for JavaScript, has been released. Rewritten in Rust at its core, it cuts install times by up to 90%. Commands, settings, and the lockfile format are carried over from version 11. In reporting by Joab Jackson of The Register, it is described as a frictionless speedup.
Bloated dependencies have become the norm in development work. In large monorepos, waiting for installs stalls work. This overhaul directly addresses that bottleneck. Its hallmark is higher performance with compatibility preserved.
Aim of the New Version:
Maintaining Full Backward Compatibility
Current maintainer Zoltan Kochan emphasized reducing the migration burden. Commands, flags, settings, and the lockfile format are inherited from 11. Documentation covers both versions, so no changes to usage are required.
Upgrading should not feel like a migration. The commands, flags, settings, and lockfile format of pnpm 11 all carry over, and the documentation covers both versions,
The above is a direct quote from Kochan. It clearly states a policy of not making an upgrade feel like a migration. Existing automation scripts and continuous integration workflows can be maintained. For operations staff, the barrier to adoption can be considered low.
Thorough backward compatibility makes sense as an adoption strategy. Switching package managers involves learning and validation costs. By eliminating differences, only the performance gains remain. Users can benefit from faster speeds without taking risks.
Faster Processing Times, by the Numbers
The benchmarks shared by the project team show a clear difference. pnpm 12 took 5.19 seconds to install an uncached sample package. Under the same conditions, pnpm 11 took 8.22 seconds and npm took 47.7 seconds. Even by simple comparison, that is about 3 seconds faster than the previous version.
With the dedicated registry server pnpr as the backend, the time drops to 3.37 seconds. pnpr is also a registry built in Rust. By using native code on both the client and server sides, latency was cut. The claimed up to 90% reduction should be seen as a figure achieved under specific conditions.
Comparative benchmarks against Bun and Yarn were also attempted. The results were withdrawn due to flaws in the testing procedure. Sarah Gooding, vice president at security company Socket, explained the background. She still noted that significant reductions were achieved in specific cases.
Technical Background of the Core Rust Rewrite
Development of the core binary began in April. It removes overhead associated with filesystem handling via Node.js. The published composition is 65.9% Rust and 33.5% TypeScript. The remainder consists of auxiliary files and configuration.
Package installation is dominated by fetching metadata and tarballs. Extraction, dependency graph resolution, and linking are also heavy loads. It was noted as an area well suited to parallel processing and native code. Vice President Gooding’s explanation captures this characteristic accurately.
The key is choosing a path that does not go through an ECMAScript runtime. Mass creation of files and hard links tends to cause waits. The Rust rewrite allows direct use of thread-level parallelism and ownership management. The effect could be even greater for the huge dependency graphs of monorepos.
Efficiency Through Shared Storage and Supply
Chain Security
pnpm was created in 2016 by Rico Sta. Cruz. At the time, npm was considered slow and disk-hungry. The cause was its design of copying duplicate dependencies individually. pnpm eliminated this waste with content-addressable storage.
Even if the same archive is needed by 100 applications, it is fetched only once. A single copy is kept in the store and referenced elsewhere via links. This reduces both disk usage and transfer volume. The combination of faster speeds and resource savings won support.
npm itself and its registry were acquired by GitHub in 2020. Its use expanded as the de facto standard for JavaScript. At the same time, supply chain compromise incidents have continued. Balancing speed and security has become the challenge for package managers.
Socket analyzed this update from a security perspective. Faster speeds through native code leave more room for verification. The time saved can be devoted to detecting malicious packages and verifying provenance. The view that performance improvements provide a foundation for security measures also holds.
Editorial Opinion
Regarding the short-term impact. Organizations with monorepos are likely to move forward with adoption testing. Because command compatibility is preserved, changes to continuous integration scripts will be minimal. Testing of pnpr in combination is also likely to progress, with replacement of internal registry mirrors up for discussion. We assess that shorter install times will accelerate development iterations.
From a long-term perspective. The shift of package manager core processes to native code is likely to take hold. Combined with the case of Bun, the migration of JavaScript tooling to Rust is assessed as becoming a trend. Mixed TypeScript and Rust configurations may also become common. We expect an approach that discusses supply chain defense and speed together to spread.
Questions from the editors. How long can compatibility be maintained. Will further native implementation increase the complexity of the compatibility layer. Is disclosure of benchmark conditions sufficient. We assess that accumulation of reproducible measurements by third parties is needed.
References
- “JavaScript installer pnpm recast in Rust because ECMAScript can’t keep up”, by Joab Jackson — The Register, 2026-09-04T12:22:00.000Z (ARR)
- Source URL: https://www.theregister.com/devops/2026/09/04/javascript-installer-pnpm-recast-in-rust-because-ecmascript-cant-keep-up/5294394
Frequently Asked Questions
- Can I keep my existing settings when upgrading to pnpm 12?
- Commands, flags, settings, and the lockfile format are carried over from pnpm 11. Documentation supports both versions. No major rewrite of automation scripts is needed, so you get just the performance gains.
- How much faster is it?
- In the project team's measurements, an uncached sample package took 5.19 seconds, versus 8.22 seconds for version 11 and 47.7 seconds for npm. With the dedicated registry server pnpr, it drops to 3.37 seconds. The up to 90% reduction applies under specific conditions.
- Why was the port to Rust necessary?
- Package installation is dominated by fetching metadata, extraction, dependency resolution, and linking, which suit parallelization. Filesystem handling overhead via Node.js was the bottleneck. Native code allows direct use of parallel processing and resource management.
Comments