pnpm vs npm vs Yarn: Node.js Package Manager Comparison 2026

Choosing the wrong package manager doesn’t break your app — but it quietly bleeds your team. Slow CI pipelines, bloated node_modules, mysterious lockfile conflicts, and monorepo tooling that fights you at every step: these are the real costs. In 2026, three package managers dominate Node.js development: npm, Yarn, and pnpm. This guide gives you the technical depth to pick the right one.

Quick Comparison: At a Glance

	npm	Yarn (Berry / v4)	pnpm
Install speed (cold)	Baseline	~1.5× faster	~2–3× faster
Install speed (cached)	Baseline	~2× faster	~3–5× faster
Disk usage	High (flat duplication)	Medium (PnP deduplication)	Very low (content-addressed store)
Lockfile	`package-lock.json`	`yarn.lock`	`pnpm-lock.yaml`
Workspace support	Yes (npm workspaces)	Yes (Yarn workspaces)	Yes (best-in-class)
Monorepo tooling	Basic	Good (Yarn Berry + PnP)	Excellent (strict isolation)
Phantom deps	Yes (leaks)	No (PnP enforced)	No (symlink isolation)
Plug’n’Play (PnP)	No	Yes (optional/default in v4)	No
Node.js bundled	Yes (Corepack)	Via Corepack	Via Corepack
Active maintenance	npm Inc. / GitHub	Meta OSS	Open Collective

What Is a Package Manager Doing, Exactly?

Before the benchmarks, it helps to understand what happens during npm install:

Resolve the full dependency tree from package.json and the lockfile
Fetch tarballs from the registry (or cache)
Extract packages into node_modules
Link binaries in .bin/

The three managers diverge sharply at steps 3 and 4 — and that’s where the real differences live.

npm: The Default You Already Know

npm ships with Node.js. You already have it. That is, genuinely, its strongest argument.

How npm handles node_modules

npm uses flat hoisting: all packages (including transitive dependencies) are lifted to the top-level node_modules/. The goal was to avoid the deep nesting of npm v1/v2, which caused path-length issues on Windows.

node_modules/
  express/
  lodash/        ← hoisted from express's deps
  mime/          ← hoisted from express's deps
  your-app-code → can accidentally require('lodash') even if you didn't list it

The flat model works until it doesn’t. You can require('lodash') without declaring it, which is a phantom dependency — code that works locally but silently breaks when a dependency stops using lodash internally.

npm install speed

# Cold install (no cache), react + next.js project ~500 deps
npm install           # ~45s
yarn install          # ~28s
pnpm install          # ~18s

# Warm cache (subsequent installs)
npm install           # ~25s
yarn install          # ~12s
pnpm install          # ~5s

Benchmarks measured on Apple M2, 1Gbps network, Node.js 22. Results vary by project and machine.

npm workspaces

Since npm v7, workspaces are supported:

// package.json (root)
{
  "workspaces": ["packages/*"]
}

npm install                    # install all workspace deps
npm run build --workspace=packages/ui
npm exec --workspace=packages/api -- node index.js

npm workspaces work fine for small monorepos but lack the isolation guarantees and filtering capabilities of pnpm workspaces.

Yarn Berry (v4): The Opinionated Modernizer

Yarn 1 (“Classic”) is in maintenance mode. Yarn Berry (v2+, now v4) is a complete rewrite with a radically different architecture. Be aware: Yarn v1 and Yarn Berry are nearly incompatible — their lockfiles, configuration, and plugin systems are entirely different.

Plug’n’Play (PnP): No node_modules

Yarn Berry’s flagship feature is PnP, which eliminates node_modules entirely:

.yarn/
  cache/        ← zip archives of packages
  releases/     ← yarn binary itself (zero-installs)
.pnp.cjs        ← the resolver map

Instead of unpacking packages into folders, Yarn generates a .pnp.cjs resolution map. Node.js is patched at startup to use this map. The result:

Zero-install repositories: commit .yarn/cache/ and skip yarn install in CI entirely
No phantom deps: if a package isn’t in your package.json, you can’t import it — PnP enforces this at resolution time
Faster startup: no disk scanning for node_modules

The PnP compatibility catch

Not every tool works with PnP out of the box. Tooling that hard-codes node_modules paths (some webpack configs, some Jest setups, some editors) needs explicit SDKs:

yarn dlx @yarnpkg/sdks vscode   # fix VS Code TypeScript support
yarn dlx @yarnpkg/sdks base     # fix other editors

This friction is why many teams stay on Yarn 1 or switch to pnpm instead.

Yarn lockfile format

yarn.lock is human-readable but verbose:

express@npm:^4.18.0:
  version: 4.18.3
  resolution: "express@npm:4.18.3"
  dependencies:
    accepts: ^1.3.8
    ...
  checksum: sha512/abc123...
  languageName: node
  linkType: hard

pnpm: The Speed and Isolation Champion

pnpm is the fastest-growing package manager in the Node.js ecosystem. Its core innovation is the content-addressable store.

The content-addressable store

Instead of copying packages into each project’s node_modules, pnpm stores every version of every package once in a global store (typically ~/.pnpm-store/), then hard-links files into your project:

~/.pnpm-store/v10/
  files/
    00/a1b2c3...  ← actual file content, by hash
    01/d4e5f6...
    ...

When you install [email protected] in 10 different projects, the files exist exactly once on disk — each project’s node_modules/lodash/ is just a set of hard links pointing at the store.

# Disk usage for 100 projects each with react, next.js, lodash
npm install:   ~47 GB (100 × ~470 MB)
pnpm install:  ~1.2 GB (shared store + project-specific symlinks)

This isn’t a hypothetical: teams running many Node.js microservices or a large monorepo save tens of gigabytes.

Strict node_modules isolation

pnpm’s node_modules structure uses symlinks and a .pnpm/ virtual store, not flat hoisting:

node_modules/
  express/        ← symlink → .pnpm/[email protected]/node_modules/express/
  .pnpm/
    [email protected]/
      node_modules/
        express/  ← actual files (hard-linked from store)
        accepts/  ← express's deps, NOT hoisted to top
        mime/

Result: you cannot accidentally import a package you didn’t declare. Phantom dependencies are eliminated by construction, not by policy.

pnpm install benchmarks

# Cold install, react + next.js, ~500 deps
pnpm install         # ~18s   (2.5× faster than npm)

# Warm cache (store populated)
pnpm install         # ~4-6s  (4-5× faster than npm)

# Node_modules already present, lockfile unchanged
pnpm install         # <1s    (symlink verification only)

pnpm lockfile

pnpm-lock.yaml is more structured than Yarn’s lockfile:

lockfileVersion: '9.0'

importers:
  .:
    dependencies:
      express:
        specifier: ^4.18.0
        version: 4.18.3

packages:
  [email protected]:
    resolution: {integrity: sha512-...}
    dependencies:
      accepts: 1.3.8

Workspace & Monorepo Comparison

Monorepo support is where pnpm genuinely pulls ahead.

npm workspaces limitations

No built-in filtering syntax for partial builds
No dependency graph traversal (can’t say “build this package and all its deps”)
Basic --workspace flag only

Yarn workspaces

yarn workspaces list
yarn workspace packages/ui add react
yarn workspaces foreach --topological run build  # build in dep order

Yarn Berry’s foreach --topological is excellent for ordered builds, but requires the Yarn CLI for every developer.

pnpm workspaces (best-in-class)

# pnpm-workspace.yaml
packages:
  - 'packages/*'
  - 'apps/*'

pnpm install                          # install all workspaces
pnpm --filter @myapp/ui add react     # add dep to specific package
pnpm --filter @myapp/api... run build # build api + all its deps
pnpm --filter ...[HEAD~1] run test    # test only packages changed since last commit

The --filter with ... and [git-ref] selectors is extremely powerful for CI: you only rebuild what changed. Combined with Turborepo or Nx, pnpm workspaces form the foundation of most high-performance monorepo setups in 2026.

# turbo + pnpm: the dominant monorepo setup
pnpm add -D turbo -w
# turbo.json configures pipeline, pnpm handles packages

Phantom Dependencies: Why They Matter

A phantom dependency is a module you require() without listing in your package.json:

// Works today — lodash is hoisted from express's deps
const _ = require('lodash');

// Breaks tomorrow when express removes lodash as a dep
// or you switch to pnpm/Yarn PnP

With npm’s flat hoisting, this is silent and common. It’s a subtle form of tech debt that causes mysterious CI failures when packages update.

Both pnpm and Yarn Berry enforce strict isolation, so this class of bug simply doesn’t exist.

Migration Guide: npm/Yarn → pnpm

Migrating to pnpm is usually a half-day task. Here’s how:

Step 1: Install pnpm

# Via Corepack (recommended, Node.js 16.9+)
corepack enable
corepack prepare pnpm@latest --activate

# Or via npm
npm install -g pnpm

Step 2: Import your existing lockfile

# From npm
pnpm import           # reads package-lock.json → pnpm-lock.yaml

# From Yarn v1
pnpm import           # reads yarn.lock → pnpm-lock.yaml

Step 3: Delete old artifacts and install

rm -rf node_modules package-lock.json yarn.lock
pnpm install

Step 4: Fix phantom dependencies (if any)

# pnpm will error on first use of undeclared deps
# Add them explicitly
pnpm add lodash

Step 5: Update scripts and CI

# package.json scripts don't change
# CI: replace npm ci with pnpm install --frozen-lockfile

# GitHub Actions example:
- uses: pnpm/action-setup@v4
  with:
    version: 9
- run: pnpm install --frozen-lockfile
- run: pnpm run build

Step 6: Enable the store in CI cache

# GitHub Actions — cache the pnpm store
- name: Get pnpm store directory
  run: echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_ENV

- uses: actions/cache@v4
  with:
    path: ${{ env.STORE_PATH }}
    key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
    restore-keys: ${{ runner.os }}-pnpm-

With this cache, your CI warm installs become near-instant.

Common Gotchas

pnpm gotchas

Peer dependency strictness: pnpm warns loudly (or errors) on unmet peer deps that npm silently accepts. Fix them explicitly or use peerDependencyRules in .npmrc:

# .npmrc
auto-install-peers=true
strict-peer-dependencies=false   # if you need to soften it

Tools that expect flat node_modules: Some legacy tools (older webpack configs, certain Jest setups) break with pnpm’s symlinked structure. Fix with:

# .npmrc — legacy compat (slower, not recommended long-term)
node-linker=hoisted

Yarn Berry gotchas

Editor integration: requires running yarn dlx @yarnpkg/sdks for TypeScript and ESLint to work in VS Code.

PnP incompatible packages: some native modules or packages with __dirname-based resolution fail with PnP. Use packageExtensions in .yarnrc.yml to patch them, or fall back to nodeLinker: node-modules mode.

When to Choose Each

Choose npm if:

You need zero configuration or zero onboarding cost
You have a simple single-package project
You’re deploying to environments where only npm is guaranteed
Your team is junior and you want the path of least friction

Choose Yarn Berry if:

You want zero-install CI (commit the cache, skip install entirely)
You care deeply about phantom dependency enforcement via PnP
You’re building tooling and want the plugin ecosystem
Your team is experienced and willing to handle PnP quirks

Choose pnpm if:

You’re building a monorepo (this should be your default)
CI speed and disk usage matter (they always do at scale)
You want strict isolation without PnP’s compatibility quirks
You’re running Turborepo or Nx (both pair excellently with pnpm)
You have many Node.js services sharing dependencies

The 2026 verdict: For most teams starting a new project — especially anything with multiple packages — pnpm is the default choice. It’s the fastest, most disk-efficient, and has the best monorepo tooling. npm remains the right choice for maximum compatibility. Yarn Berry is the right choice if zero-install CI is a priority.

Key Takeaways

pnpm is 2–5× faster than npm and uses dramatically less disk space via content-addressed storage
Yarn Berry’s PnP eliminates phantom deps entirely but has compatibility overhead
pnpm’s workspace filtering (--filter ...[HEAD~1]) is the most powerful monorepo CI optimization available
Migration from npm → pnpm takes ~half a day: pnpm import converts your lockfile automatically
Phantom dependencies are a silent time-bomb with npm’s flat hoisting; both pnpm and Yarn Berry solve this structurally
For CI, cache the pnpm store (not node_modules) for best results — warm installs drop to under 5 seconds

All benchmark numbers are indicative and will vary based on project size, machine specs, and network. Run your own benchmarks with pkg-install-bench for precise measurements on your stack.