devtools
guide
20 Oct 2026
Four Node package managers, one dependency set, and what the second project costs
On one project they land within 25 percent of each other. Clone a second repo with the same dependencies and the gap becomes 5.4x, and one of them writes five files where the others write nine thousand.
By Purvansh Parmar
Checked 2026-10-21
Read 7 min
Entries 4
Install the same dependencies with npm and with pnpm and the disk difference is 12 MB. That is nothing. It is also the comparison everybody runs, and it is the wrong one, because these tools are not competing on what one project costs so much as on what the fourth checkout sitting on your laptop costs. On that question the gap stops being a rounding error: a second copy of the same dependency set cost npm 172 MB and cost pnpm 32. One of the four does not play the game at all.
How this was checkedInstalled the same eleven dependency package.json twice, in two separate project directories, under four layouts in a clean container, and measured what was left on disk with the shared store counted once. One project is unremarkable: 106 to 132 MB, and the three that build a node_modules produce within one percent the same number of files. The second project is where they separate, costing npm another 172 MB and pnpm another 32. Yarn's Plug'n'Play left no node_modules at all: five files in the project and 242 zipped archives in a shared cache.
What I compared on
- disk for two projects with the store counted once, which is the marginal cost of the next repo you clone
- files and directories created, which is what every watcher, scanner and backup walks
- disk for a single project, the number everyone quotes
Keeps one content addressed store per machine and links packages into each project rather than copying them.
Wins
It is the only layout here where the cost of the next repository is close to zero, which is the real shape of a developer machine holding six checkouts of things that all depend on the same React.
Loses
It creates 1,267 directories against npm's 774, a 64 percent increase, because the nested store layout is directories all the way down. Anything that watches or walks the tree pays for those, and the strict layout still breaks packages that reach for undeclared dependencies.
32 MB for the second project106 MB for one1,267 directories
Yarn berry's default linker, which resolves modules from zipped archives and never creates a node_modules directory.
Wins
It is the only layout that changes the file count rather than rearranging it: 242 files on disk against roughly 9,470 for every node_modules based installer. Nothing has to walk a tree that does not exist.
Loses
Everything that assumes it can read a path inside node_modules has to be patched or run through yarn, which is still a real tax on older tooling, editors and anything shelling out to a binary. Its second project also cost 50 MB, more than pnpm's 32.
5 files in the project242 files in the cache50 MB for the second project
The default, which copies a full flat tree of packages into every project that asks for them.
Wins
It is already installed, the flat node_modules layout is what every tool in the ecosystem assumes, and nothing you run will be surprised by it. For a machine with one or two projects teh duplication is irrelevant.
Loses
Every project pays the full price, so disk grows linearly with how many repositories you have checked out. Ten repos sharing a dependency set means ten copies of it, which is 1.7 GB of the same bytes.
172 MB for the second project118 MB for one9,470 files
The 1.x line still pinned in a great many repositories, with its own cache and the same flat output shape.
Wins
It is stable, still maintained in the versions people pin, and the lockfile format is readable in a review, which is a genuine advantage over its competitors when a dependency change needs scrutiny.
Loses
It is last in the table on every axis measured. 12 percent more disk than npm for one project and 9 percent more for the second, with no structural difference to show for it.
188 MB for the second project132 MB for one9,510 files
Side by side
| One project | Two projects | Second costs | Files |
|---|
| pnpm 12.14.0 | 106 MB | 138 MB | 32 MB | 9,415 |
| Yarn PnP 4.18.1 | 1 MB + 133 MB cache | 184 MB | 50 MB | 5 + 242 |
| npm 10.9.9 | 118 MB | 290 MB | 172 MB | 9,470 |
| yarn 1.22.22 | 132 MB | 320 MB | 188 MB | 9,510 |
Verdict
Use pnpm if your machine holds more than two checkouts. Thirty-two megabytes against 172 for the next one is the whole argument, and nothing with a node_modules comes close. The result worth remembering is the one that did not move: every layout that builds a node_modules wrote between 9,415 and 9,510 files, within one percent of each other. So if your editor or your container build is slow because of how many files node_modules holds, changing installer will not help you, and pnpm hands you 64 percent more directories to walk. Yarn Plug'n'Play is the only entry that answers that complaint, at 242 files, and it bills you in toolchain compatibility instead.
Sources