pnpm Is Better, but npm Is Everywhere
Every Node.js developer starts with npm. It ships with Node, requires zero setup, and powers millions of projects. If you’ve ever run npm install, you’ve used the world’s largest package registry.
But npm has real shortcomings — bloated node_modules folders, slower installs, and loose dependency resolution that lets bugs hide in production. That’s where pnpm steps in. It’s faster, stricter, and dramatically more efficient with disk space. The trade-off? You have to install it yourself, and some older tooling assumes a flat node_modules layout.
This guide breaks down every meaningful difference so you can pick the right tool for your next project. For a broader comparison that includes Yarn, see our npm vs pnpm vs Yarn breakdown.
Head-to-Head Comparison
| Feature | pnpm | npm |
|---|---|---|
| Install speed (cold) | ~12 s (medium project) | ~28 s |
| Install speed (warm cache) | ~4 s | ~14 s |
| Disk usage | Content-addressable store, shared across projects | Full copy per project |
| Disk savings | 50-70% less space | Baseline |
| node_modules structure | Symlinked, non-flat | Flat (hoisted) |
| Phantom dependency prevention | Yes — strict by default | No — hoisting exposes undeclared deps |
| Monorepo workspaces | First-class, filtering, parallel tasks | Basic workspace support |
| Lock file | pnpm-lock.yaml | package-lock.json |
| Ships with Node.js | No (install via corepack enable) | Yes |
| npm registry compatible | 100% | 100% |
| Peer dependency handling | Strict, auto-install option | Strict since npm 7+ |
| Patching packages | pnpm patch built-in | Requires patch-package |
| Side-effects cache | Yes | No |
| Overrides syntax | pnpm.overrides in package.json | overrides in package.json |
How pnpm Saves Disk Space
npm creates a separate node_modules folder for every project. If you have ten React projects, you get ten copies of React and all its transitive dependencies. On a typical machine this eats tens of gigabytes fast.
pnpm takes a fundamentally different approach. It maintains a single content-addressable store on your disk, usually at ~/.local/share/pnpm/store. Every version of every package is stored there exactly once. When you run pnpm install, pnpm creates hard links from the store into your project’s node_modules, then uses symlinks to wire up the dependency tree.
The result: if ten projects depend on react@19.1.0, only one copy exists on disk. Each project links to it. In practice this saves 50-70% of disk space compared to npm, and the savings grow with every additional project on your machine.
# npm: each project gets its own copy
project-a/node_modules/react/ → 4.2 MB
project-b/node_modules/react/ → 4.2 MB (duplicate)
# pnpm: single store, hard links per project
~/.local/share/pnpm/store/react-19.1.0/ → 4.2 MB (one copy)
project-a/node_modules/react/ → hard link
project-b/node_modules/react/ → hard linkSpeed Benchmarks
pnpm is consistently faster than npm across every scenario. Here are representative numbers for a medium-sized project (~400 dependencies) measured on the same CI runner:
| Scenario | pnpm | npm |
|---|---|---|
| Cold install (no cache, no lockfile) | ~12 s | ~28 s |
| Warm install (with cache + lockfile) | ~4 s | ~14 s |
| Adding a single dependency | ~3 s | ~8 s |
| CI install (frozen lockfile) | ~6 s | ~18 s |
The speed advantage comes from three things: parallel fetching, the content-addressable store (packages already on disk don’t need downloading), and less I/O because hard links avoid copying files. npm 10+ closed the gap somewhat with improved caching, but pnpm still leads by a wide margin. If you’re also evaluating runtimes, our Bun vs Node comparison covers the execution side.
Monorepo Support
Both tools offer workspaces, but the implementations differ significantly.
pnpm workspaces are purpose-built for monorepos. You define packages in pnpm-workspace.yaml and get powerful features out of the box:
--filterflag to run commands in specific packages or their dependents- Parallel task execution across workspace packages
- Shared dependencies are hoisted to a virtual store, not duplicated
pnpm deployto create a pruned production bundle for a single package
npm workspaces (available since npm 7) cover the basics — installing across packages and running scripts with --workspace flags — but lack filtering, parallelism, and the disk-efficiency gains of pnpm’s linking strategy. For large monorepos with dozens of packages, pnpm workspaces are meaningfully faster and more ergonomic.
Strictness and Phantom Dependencies
This is one of pnpm’s most important advantages and the one least understood by developers who haven’t hit the problem yet.
npm uses a flat (hoisted) node_modules layout. When you install package A, and A depends on package B, npm hoists B to the top level. Your code can then import B even though you never declared it in your own package.json. This is a phantom dependency — it works locally but can break unpredictably when B is removed or updated as a transitive dep.
pnpm prevents this entirely. Its symlinked node_modules structure only exposes packages you explicitly declared. Try to import an undeclared dependency and you get an immediate error, not a silent time bomb. This strictness catches real bugs before they reach production and makes dependency audits straightforward.
If you’re migrating from npm to pnpm and hit import errors, that’s pnpm doing its job — those imports were phantom dependencies all along. Check our pnpm cheat sheet for the commands you’ll need during migration.
When to Use Each
Choose pnpm when:
- You work on monorepos or multi-package setups
- You maintain many projects on one machine and want to reclaim disk space
- You want faster CI pipelines
- You value strict dependency resolution that catches bugs early
- You’re starting a new project with no legacy constraints
Choose npm when:
- You’re building a simple, single-package project
- You want zero setup — npm ships with Node.js
- You’re following a tutorial or docs that assume npm
- Your team or CI environment has npm-specific tooling that’s hard to swap out
- Maximum ecosystem compatibility matters more than speed
Verdict
pnpm wins on nearly every technical metric — speed, disk efficiency, strictness, and monorepo support. It’s the better tool for serious development work in 2026. The content-addressable store alone justifies the switch if you juggle multiple projects.
npm remains the safe default. It’s universal, requires no extra installation, and works everywhere without friction. For solo projects or quick prototyping, npm is perfectly fine.
The practical recommendation: use pnpm for anything you plan to maintain, and npm when convenience matters more than performance. The migration path is simple — pnpm import converts your existing package-lock.json — so switching later costs almost nothing.
FAQ
Should I switch from npm to pnpm?
If you maintain multiple projects or work in monorepos, switching to pnpm is worth it for the disk savings and speed improvements alone. The migration is simple — pnpm import converts your existing lockfile — and the strictness catches real dependency bugs you didn’t know you had.
Is pnpm faster than npm?
Yes, consistently. Cold installs are roughly 2x faster, and warm installs with cache are about 3x faster. The speed advantage comes from parallel fetching, the content-addressable store avoiding redundant downloads, and hard links reducing filesystem I/O.
Does pnpm work with all npm packages?
pnpm is 100% compatible with the npm registry and works with virtually all packages. The only edge cases are packages that rely on npm’s flat hoisting to access undeclared dependencies — these are phantom dependencies that represent real bugs in those packages.
Is pnpm good for monorepos?
pnpm is excellent for monorepos. Its workspace implementation includes powerful filtering, parallel task execution, and shared dependency storage that npm workspaces lack. Large monorepos see significant speed and disk usage improvements compared to npm or Yarn.