Do the arithmetic before you touch the lockfile. Let N be the number of workspace packages that declare the same devDependency. Under npm, each declaration can materialise as a physical copy in the tree [4]. Under pnpm, the bytes land once in a global content-addressable store outside the project, and every node_modules holds a symlink into it [5]. Copies avoided is therefore N minus 1 [2].
In the post's four-app monorepo, that is three of four copies gone, 75 percent of that dependency's bytes [1]. In a repo with a single package.json and no workspaces, N is 1, N minus 1 is zero, and however many dependencies the project has, the store has nothing in the same repo to deduplicate against [3]. That is the whole reason total dependency count is the wrong number to read: the post's fifteen-dependency example shows no noticeable difference either way [15], while duplication tracks package count [2].
The time claim is weaker than the space claim, and the author says so. Disk savings are consistent; install-time savings depend on whether the package is already in the local store, and on a CI run with a cold cache the first download weighs the same under either tool [8]. For an install-time number from someone else's pipeline to transfer to yours, you would need a warm store on the same runner, a cache that actually restored, and comparable network. The author publishes no such benchmark and declines to invent one [12], which is the correct posture and rarer than it should be.
Note the escape hatch on the npm side. npm can flatten those copies with aggressive hoisting, at the price of phantom dependencies, packages your code can import without declaring [4]. So the honest framing is not copies versus symlinks; it is copies, or a resolution graph that resolves things your manifest never asked for.
The adoption cost sits outside the package manager. What breaks is the rest of the stack that assumed npm: CI scripts, Docker images running npm ci, and dependency linters that parse package-lock.json in the format npm documents and have no handler for pnpm-lock.yaml [9]. `pnpm store status` will tell you what the store saved against a non-deduplicated install [7]; it will not tell you what the Dockerfile rewrite costs.
One caveat on sourcing. The two blocks in front of me are the same piece by the same dev.to author, English and Spanish [14], so this is one practitioner's thesis [1] relaying pnpm's own motivation docs for the store model [5], not two independent reads. The mechanism is checkable from the docs and from `pnpm store path` [7]. The thesis about where the payoff lands is an argument, and the author frames his own comparison matrix as rows to start looking at rather than closed conclusions [13].
My context: I would migrate a workspace with three or more packages sharing a toolchain, and leave a single-package service on npm, because there the migration buys a new tool the team has to learn to debug and no measurable saving [10].
