How to Choose Between npm, pnpm, and Yarn in 2026

TL;DR

pnpm for monorepos and CI-heavy workflows; npm for simplicity and broad compatibility. pnpm (~5M weekly downloads) saves 60%+ disk space via content-addressable storage and is 2-3x faster on cold installs. npm (~90M downloads, but counts itself) is the universal default — no setup, everywhere. Yarn v4 (PnP mode) is elegant but requires ecosystem buy-in. For new projects: pnpm if you care about speed/disk; npm if you want zero friction.

Key Takeaways

npm: universal default — ships with Node.js, works everywhere, no setup
pnpm: best CI/monorepo performance — 2-3x faster installs, 60% less disk
Yarn v4 (PnP): most radical — zero node_modules, faster resolution, needs IDE setup
All three: compatible with npm registry — any npm package works with any manager
pnpm workspaces: monorepo standard — used by Turborepo, most Next.js projects

The Current Landscape

The JavaScript package manager landscape settled significantly between 2023 and 2026. Three major options remain: npm, pnpm, and Yarn. Bun ships its own package manager as well, but it's primarily used when Bun is your runtime — not as a standalone tool.

npm ships with Node.js and requires zero configuration. It's the default for every tutorial, every Docker image, and every deployment platform. The npm install command is the first thing most Node.js developers learn. Its download count (~90M weekly) is inflated because npm counts itself in its own downloads, but it genuinely is the most-used package manager by a wide margin.

pnpm has won the monorepo space. Turborepo recommends it, major open-source projects like Vite, Vue, and Nuxt use it, and most new Next.js projects default to it. The core innovation is a content-addressable global store: packages are downloaded once and symlinked into each project's node_modules, rather than copied. This means a 300MB React project installs in seconds if you've installed React before, and 10 projects sharing the same packages use far less disk than 10 independent npm installs.

Yarn v4 (with Plug'n'Play) is the most architecturally different option. It eliminates node_modules entirely — packages are stored as zip archives in .yarn/cache, and a generated .pnp.cjs file patches Node.js's module resolution to read from those zips. The result is extremely fast warm installs and the ability to commit your entire dependency cache to git (zero-install CI). The trade-off is that it requires IDE plugins and team buy-in to work smoothly.

npm: The Universal Default

npm's greatest strength is that it requires nothing. Install Node.js, and you have npm. Every package on the npm registry was published with npm, and most packages are tested with it. When something goes wrong, Stack Overflow answers assume npm.

npm added workspace support in v7, which covers the monorepo use case reasonably well. npm workspaces lets you manage multiple packages in a single repository with shared dependencies hoisted to the root.

# npm comes with Node.js — no install needed
node --version  # Includes npm
npm --version   # Already there

# npm workspaces (added in npm v7)
# package.json
{
  "workspaces": ["apps/*", "packages/*"]
}

npm install          # Installs all workspaces
npm install -w apps/web react  # Install in specific workspace
npm run build --workspaces    # Run in all workspaces

The main criticisms of npm are install speed and disk usage. npm creates a flat node_modules directory using hoisting, which can produce phantom dependencies — your code can accidentally import a package that's present in node_modules because something else depends on it, without it being in your package.json. This works until a dependency upgrade removes the transitive dep that was being phantom-imported, causing a confusing breakage.

npm is the safest choice for: teams that are new to Node.js, projects where any non-standard tooling creates friction, Docker images built by hand without caching strategies, and applications deployed to platforms with opinionated build environments.

pnpm: The Speed and Efficiency Winner

pnpm's architecture is fundamentally different from npm's. Instead of copying packages into each project's node_modules, it maintains a global content-addressable store at ~/.pnpm-store/. Every file in every package is stored by a content hash. When you install a package, pnpm creates hard links or symlinks from the global store to your project — the bytes are on disk exactly once, no matter how many projects use that package.

# Install pnpm
npm install -g pnpm
# Or: curl -fsSL https://get.pnpm.io/install.sh | sh

# Same commands as npm:
pnpm install
pnpm add react
pnpm add -D typescript
pnpm run build
pnpm test

# Key differentiator: global content-addressable store
# ~/.pnpm-store/v3/ — packages stored by hash, not name
# Every project symlinks to the store
# react@18.2.0 stored ONCE even if 10 projects use it

The practical result is that cold installs are 2-3x faster than npm (less network bandwidth needed after the first install, faster file operations), and warm installs are nearly instant. For a Next.js app with 200 packages, npm takes ~45 seconds on a cold install; pnpm takes ~18 seconds. On warm installs with cache, pnpm is consistently under 5 seconds.

pnpm also enforces strict dependency isolation. Unlike npm's flat node_modules, pnpm's node_modules structure prevents phantom dependencies — code can only import packages explicitly listed in its own package.json. This catches dependency hygiene issues early rather than having them surface as mysterious breakages during upgrades.

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

# pnpm workspace commands
pnpm install                        # Install all workspaces
pnpm add react --filter @myapp/web  # Add to specific package
pnpm run build --filter '...'       # All packages
pnpm run build --filter '@myapp/web...'  # web and its dependencies

# .npmrc for pnpm
shamefully-hoist=true      # Compatibility with packages that expect flat node_modules
strict-peer-dependencies=false
dedupe-peer-dependents=true

The shamefully-hoist option is worth knowing about. Some packages (particularly older ones) expect to be able to resolve packages that aren't their direct dependencies. Setting shamefully-hoist=true in your .npmrc reverts pnpm to npm-like flat hoisting for that project, sacrificing the strictness guarantee but fixing compatibility issues.

Yarn v4 (PnP): The Different Approach

Yarn v4 with Plug'n'Play is architecturally the most interesting option. It doesn't create a node_modules directory at all. Instead, packages are stored as zip files in .yarn/cache/, and a generated .pnp.cjs file maps every require('package-name') call to the exact zip archive location. Node.js resolution is intercepted by this loader.

# Yarn v4 with Plug'n'Play (no node_modules)
# Install Yarn via Corepack:
corepack enable
corepack prepare yarn@stable --activate

# Initialize
yarn init -2
# Creates .yarn/releases/yarn-4.x.x.cjs

# Install
yarn install
# Creates .yarn/cache/ (zip files) + .pnp.cjs
# NO node_modules directory created

The advantages are real. Install times are extremely fast once the cache is warm because there are no files to copy or symlink — just the .pnp.cjs resolver file to generate. Dependency resolution is completely strict — it's physically impossible to import a package that isn't in your manifest. And with the zero-install workflow, you commit .yarn/cache to your repository and CI never needs to download dependencies at all.

The disadvantages are also real. IDE support requires installing Yarn SDK integrations (yarn dlx @yarnpkg/sdks vscode). Some native addons and packages that expect a standard node_modules structure don't work with PnP. The .pnp.cjs file can be hard to debug when something goes wrong. And the whole team needs to be on board — a developer who doesn't have Yarn set up properly will have a broken development environment.

Yarn v4 is the right choice for teams that have bought into the stack completely: everyone uses the same IDE, the CI environment is well-controlled, and the performance gains in a large codebase justify the upfront setup investment.

Monorepo Considerations

For monorepos, pnpm workspaces have become the de facto standard. The combination of fast installs, strict dependency isolation (preventing packages from accidentally importing each other's deps), and the --filter flag for running commands on subsets of packages makes pnpm exceptionally well-suited.

Turborepo, the most popular monorepo build system, has pnpm as its recommended package manager. Nx also supports pnpm well. The pnpm -r run build command runs build in every package, respecting dependency order.

Yarn workspaces with PnP are an equally strong option for monorepos and offer the zero-install advantage. npm workspaces work but are slower and offer fewer filtering and orchestration options. If you're starting a new monorepo in 2026, pnpm is the default choice unless your team has strong reasons to prefer Yarn PnP.

CI/CD Strategy

Package manager choice has a significant impact on CI build times, especially in large monorepos. pnpm is the fastest option for CI environments that can cache the global store between runs.

# GitHub Actions with pnpm
- uses: pnpm/action-setup@v4
  with:
    version: 9

- uses: actions/setup-node@v4
  with:
    node-version: '22'
    cache: 'pnpm'

- run: pnpm install --frozen-lockfile

The actions/setup-node action's cache: 'pnpm' option caches ~/.pnpm-store between runs. On a cache hit, pnpm install with a frozen lockfile completes in under 10 seconds for most projects, compared to 45+ seconds for an uncached npm install.

Yarn's zero-install approach goes further: by committing .yarn/cache to the repository, you eliminate the install step entirely. yarn install with a committed cache completes in under 2 seconds because it's just reading from the repo. The trade-off is that your repository size increases by however large your dependency cache is — typically 50-150MB for a medium-sized project.

Migrating Between Package Managers

Switching from npm to pnpm is the most common migration and takes about 5 minutes:

# npm → pnpm:
# 1. Delete node_modules and package-lock.json
rm -rf node_modules package-lock.json
# 2. Install pnpm
npm install -g pnpm
# 3. Install dependencies
pnpm install
# Creates pnpm-lock.yaml (replaces package-lock.json)

The pnpm install command reads your existing package.json and installs everything. If you hit issues with packages that expect flat node_modules, add shamefully-hoist=true to .npmrc. Most migrations work without this flag; it's only needed for packages that have poor dependency hygiene.

To enforce the package manager choice and prevent developers from accidentally running npm install in a pnpm project, use the packageManager field in package.json:

{
  "packageManager": "pnpm@9.0.0"
}

Node.js's Corepack feature reads this field and will error if the wrong package manager is used.

Package Health Table

Package Manager	Weekly Downloads	Disk Usage	Install Speed	Workspaces	PnP Support
npm	~90M (self-counted)	High (per-project copies)	Baseline	Good	No
pnpm	~5M	Low (global store, shared)	2-3x faster	Excellent	No
yarn (v4)	~2M	Minimal (zip cache)	Fastest (warm)	Excellent	Yes

Decision Guide

Situation	Pick
First project, no preferences	npm — zero friction
Monorepo with Turborepo	pnpm — designed for this
CI build time is critical	pnpm — fastest installs with cache
Disk space is constrained	pnpm — shared global store
Multiple projects on one machine	pnpm — stores once globally
Team unfamiliar with package managers	npm — lowest learning curve
Maximum strictness on dependencies	Yarn PnP
Team uses zero-install workflow	Yarn PnP (commit cache to git)
Vercel/Netlify deployment	All three work — pnpm is recommended
Docker builds	pnpm (cache the store layer)
New monorepo from scratch	pnpm
Existing npm project, want improvement	pnpm (5-minute migration)

For more on reducing node_modules footprint, see the guide to reducing node_modules size. Compare npm and pnpm package health on the pnpm package page. And if you're choosing a runtime as well, see best JavaScript runtimes in 2026.

The 2026 JavaScript Stack Cheatsheet