pnpm

A JavaScript package-manager whose whole design is an argument about where packages live. Read from the project's own Motivation page — first-party, and describing its own mechanism, which is the part a project is authoritative on.

One copy on the disk, hard-linked everywhere

Packages go into a content-addressable store: "All the files are saved in a single place on the disk. When packages are installed, their files are hard-linked from that single place, consuming no additional disk space."

Because the store is addressed by file rather than by package, an update is incremental at file granularity: "if it has 100 files, and a new version has a change in only one of those files, pnpm update will only add 1 new file to the store, instead of cloning the entire dependency just for the singular change." The saving therefore scales with the number of projects on the machine, not the size of any one of them.

A symlink tree instead of a flat one

"By default, pnpm uses symlinks to add only the direct dependencies of the project into the root of the modules directory." npm and Yarn hoist everything to the root, so a package can import something it never declared. Under pnpm it cannot — the file is on disk, in the store, and simply not reachable from that project's node_modules.

This is the same move Protobuf makes with a schema and schema-driven-codegen makes with a generated client: put the constraint somewhere the developer cannot casually bypass. The cost is identical too — packages that relied on the loose behaviour break, and the ecosystem calls that a pnpm bug for years afterwards.

Speed, as claimed

Installation runs in three concurrent stages — resolve-and-fetch to the store, compute the directory structure, link into node_modules — which the docs say is "significantly faster than the traditional three-stage installation process" where the three run in sequence.

No number is attached to that claim on this page, and this wiki does not supply one. Practitioner migration write-ups quote 3–5× faster CI installs and 60%+ disk reductions; every one found while hunting was a personal blog with an unstated baseline, no repetition and no cache-state disclosure, so none is cited here. See the growth-edge note in synthesis.md.

A measurement, 2026-09-22. package-manager-benchmark-cheezone times pnpm against npm, Bun, nub and aube on two pinned Vite projects with the cache state stated. Warm installs: pnpm 0.28 s vs npm 5.50 s on one fixture, 1.01 s vs 11.45 s on the other. Cold installs point the same way (3.4 s vs 26–39 s) but rest on two samples each with a large spread. It is one person's harness, first run that day, so it supports "much faster when warm" and not yet a cold-install ratio. Disk use is still unmeasured.

Related

package-manager · package-manager-benchmark-cheezone · monorepo · schema-driven-codegen · developer-tooling · synthesis