npm vs pnpm vs Yarn (2026) — Speed, Disk Usage, Monorepo, and Which to Pick

Three package managers, one package.json. They install the same dependencies from the same registry. The differences are in HOW they install, WHERE the files live on disk, and how well they scale to monorepos.

At-a-glance comparison

	npm 10+	pnpm 9+	Yarn 4 (Berry)
Ships with Node?	Yes	No (corepack enables it)	No (corepack enables it)
Install speed (cold)	Baseline	1.5-3x faster	1.2-2x faster than npm
Install speed (warm)	~1x	3-5x faster	2-3x faster
Disk usage (100 projects, same deps)	Very high (per-project copies)	Very low (global content-addressed store)	Medium (Zero-Install: in-repo cache)
Lockfile	package-lock.json	pnpm-lock.yaml	yarn.lock
Workspaces / monorepo	Yes (7+)	Yes (excellent)	Yes (excellent, with Plug'n'Play)
node_modules layout	Flat (hoisted)	Symlinked (strict — no phantom deps)	Flat OR Plug'n'Play (no node_modules)

Real numbers — cold install of a mid-size Next.js app

~1200 dependencies, empty cache, clean node_modules:

• npm: ~85 seconds
• pnpm: ~28 seconds
• Yarn 4: ~40 seconds

Warm install (cache full, node_modules deleted):

• npm: ~35 seconds
• pnpm: ~9 seconds
• Yarn 4: ~15 seconds

The killer feature of each

npm — the boring safe choice

Ships with Node. No corepack setup. Compatible with every CI/CD system, every deploy platform. If nothing weird has to happen, npm just works. The slowest of the three but modern npm (10+) is far faster than npm 6.

pnpm — disk usage will blow your mind

pnpm stores each unique file ONCE in a global store, then symlinks it into each project's node_modules. 20 projects that all use React? React is on disk once. Disk usage difference: our devs went from 45GB of node_modules to 3GB after switching.

Second big win: pnpm's strict node_modules layout. Only packages you explicitly declared as dependencies are accessible. This catches "phantom dependency" bugs where your code imports something you never listed in package.json but that happens to be installed as a sub-dependency of something else.

Third win: monorepo support is best-in-class. pnpm --filter is intuitive, catalog: for shared dep versions across the monorepo is genuinely useful.

Yarn 4 (Berry) — Plug'n'Play changes everything

Yarn Berry's Plug'n'Play mode eliminates node_modules entirely. Instead, Yarn maintains a .pnp.cjs file that maps every import to its exact location in the cache. Startups are much faster (no walking node_modules), and "works on my machine" bugs from stray hoisting disappear.

Trade-off: PnP requires tools to opt in. Most modern bundlers (webpack, esbuild, Vite) support it, but occasional TypeScript / IDE tooling issues remain. If you can pay the tooling tax, it's fantastic. If not, use Yarn's classic node-modules mode (still faster than npm).

Monorepo decision

• 1-3 packages, mostly independent — any of them work; pick npm for simplicity
• 10+ packages sharing many deps — pnpm workspaces is the default recommendation in 2026
• Very large monorepo with strict boundary enforcement — pnpm or Yarn PnP (both prevent phantom deps)
• Nx or Turborepo user — both work with any of the three, but pnpm's efficient store makes builds noticeably faster

When to switch away from npm

Small project (< 200 deps)? Don't bother. The speed difference on install is small in absolute terms.

Bigger project or monorepo? Switching to pnpm or Yarn is usually less than a day of work:

1. rm -rf node_modules package-lock.json
2. corepack enable (Node 16.10+ ships corepack)
3. pnpm install (or yarn install)
4. Commit the new lockfile, delete the old
5. Update CI cache to key on the new lockfile name

Related

How to manage Node versions (nvm, fnm, volta) · JSON formatter for reading lockfile diffs.