pnpm vs npm vs Yarn: Which JavaScript Package Manager Should You Use in 2025?

Choosing a JavaScript package manager might seem like a minor decision, but it directly impacts your development speed, disk usage, CI/CD pipeline costs, and team collaboration. In 2025, three package managers dominate the ecosystem: npm (the original default), Yarn (Facebook’s answer to npm’s early shortcomings), and pnpm (the performance-focused newcomer that has gained massive traction). This comprehensive comparison examines each tool across the metrics that matter most so you can make an informed choice for your next project.

A Brief History of JavaScript Package Managers

Understanding where each tool came from helps explain their design philosophies and trade-offs today.

npm launched in 2010 alongside Node.js and quickly became the default package manager shipped with every Node installation. For years it was the only realistic option, but its early versions suffered from non-deterministic installs, deeply nested node_modules trees, and performance issues that frustrated developers working on large projects. If you are just getting started with Node.js, our beginner’s guide to Node.js covers the fundamentals including npm basics.

Yarn (Yarn Classic, v1) appeared in 2016, built by engineers at Facebook, Google, Exponent, and Tilde. It introduced the lockfile concept (yarn.lock), deterministic installs, parallel downloads, and offline caching — all features npm lacked at the time. Yarn 2 (Berry), released in 2020, brought the controversial Plug’n’Play (PnP) approach that eliminates node_modules entirely.

pnpm (performant npm) started in 2017 with a radical idea: instead of copying every package into each project’s node_modules, store packages once in a global content-addressable store and use hard links. This single architectural decision gives pnpm dramatic advantages in disk space and installation speed that the other managers struggle to match.

Installation and Getting Started

All three managers are straightforward to install, but pnpm offers the most flexible options in 2025.

npm comes pre-installed with Node.js. You have it the moment you install Node. No extra steps required.

Yarn is installed via Corepack (bundled with Node 16.10+) by running corepack enable and then yarn init in your project. Yarn Classic (v1) is in maintenance mode; new projects should use Yarn Berry (v3/v4).

pnpm can be installed through Corepack, standalone scripts, npm itself (npm install -g pnpm), or Homebrew on macOS. The Corepack method is recommended for teams because it pins the exact pnpm version in your package.json.

How They Handle node_modules

The fundamental difference between these three tools lies in how they store and link dependencies. This single architectural decision cascades into nearly every performance and compatibility characteristic.

npm: Flat node_modules

Since npm v3, packages are hoisted into a flat node_modules structure. This solved the deeply nested path issue on Windows but introduced a new problem: phantom dependencies. Your code can accidentally import packages that are not listed in your package.json because they were hoisted from a transitive dependency. This creates fragile builds that break unpredictably when dependency trees change.

Yarn Classic: Flat with Hoisting

Yarn Classic uses the same flat hoisting strategy as npm. Yarn Berry with PnP eliminates node_modules entirely, replacing it with a .pnp.cjs file that maps package names to zip archives stored in .yarn/cache. While this is technically superior, PnP has compatibility issues with tools that expect node_modules on disk. Yarn Berry also offers a node_modules linker as a fallback.

pnpm: Content-Addressable Store + Symlinks

pnpm stores every package version exactly once in a global content-addressable store (typically ~/.local/share/pnpm/store). Each project’s node_modules uses hard links pointing to this store, and dependencies are organized using a symlinked structure that strictly mirrors the actual dependency graph. This means your code cannot access packages you have not declared — phantom dependencies are impossible. This strict approach catches real bugs that npm and Yarn silently ignore.

Performance Benchmarks (2025)

Performance varies based on project size, network conditions, and cache state. The following benchmarks reflect a mid-size project with approximately 800 dependencies, measured on an M2 MacBook Pro with a warm cache and then cold cache scenarios.

Cold Install (No Cache)

Manager	Time	Disk Usage
npm v10	38s	412 MB
Yarn Berry (PnP)	22s	198 MB
Yarn Berry (node_modules)	29s	395 MB
pnpm v9	18s	287 MB*

*pnpm’s reported disk usage reflects the project’s node_modules size, but because files are hard-linked from the global store, actual additional disk consumption is minimal if you have multiple projects sharing the same dependencies.

Warm Install (With Cache, No Lockfile Changes)

Manager	Time
npm v10	12s
Yarn Berry (PnP)	1.2s
Yarn Berry (node_modules)	8s
pnpm v9	3.5s

Yarn Berry PnP wins the warm-install benchmark because it only needs to regenerate the .pnp.cjs map — no file copying at all. pnpm is fastest for cold installs because its content-addressable store avoids downloading packages that already exist globally. npm is consistently the slowest in both scenarios.

CI/CD Impact

In continuous integration environments, install speed directly affects your bill. A team running 200 CI builds per day that saves 20 seconds per build recovers over 66 hours of compute time per month. If you are setting up CI/CD pipelines, our GitHub Actions CI/CD guide and CI/CD tools comparison cover caching strategies for all three package managers.

Monorepo Support

Monorepos — single repositories containing multiple packages — are increasingly popular for large-scale JavaScript projects. All three managers support workspaces, but the implementation quality differs significantly.

npm workspaces (added in npm v7) provide basic monorepo support. You declare workspaces in your root package.json, and npm handles cross-package linking. However, npm workspaces lack filtering commands, parallel execution, and efficient change detection that teams need for large monorepos.

Yarn workspaces are more mature, with support for constraints (workspace-level policy enforcement), parallel script execution, and focused installs that only install dependencies for specific workspaces. Yarn Berry’s workspace protocol (workspace:*) ensures internal packages always resolve to the local version.

pnpm workspaces combine strict dependency isolation with powerful filtering. The --filter flag supports glob patterns, directory-based selection, and dependency-graph-aware targeting. pnpm’s strict linking also prevents workspace packages from accidentally depending on packages hoisted from siblings — a common and hard-to-debug issue in npm and Yarn Classic monorepos.

For a deeper look at monorepo tooling that complements these package managers, see our guide to Turborepo and Nx.

Here is a practical pnpm workspace configuration for a typical monorepo:

# pnpm-workspace.yaml — Monorepo workspace configuration
packages:
  # Application packages
  - "apps/*"
  # Shared libraries
  - "packages/*"
  # Internal tooling
  - "tools/*"

# package.json (root)
{
  "name": "my-monorepo",
  "private": true,
  "scripts": {
    "build": "pnpm --filter './packages/**' run build",
    "build:apps": "pnpm --filter './apps/**' run build",
    "dev": "pnpm --filter @myorg/web-app run dev",
    "test": "pnpm -r run test",
    "test:changed": "pnpm --filter '...[origin/main]' run test",
    "lint": "pnpm -r run lint",
    "clean": "pnpm -r exec rm -rf dist node_modules",
    "deploy:staging": "pnpm --filter @myorg/api --filter @myorg/web-app run deploy"
  },
  "devDependencies": {
    "typescript": "^5.5.0",
    "prettier": "^3.3.0"
  },
  "engines": {
    "node": ">=20.0.0",
    "pnpm": ">=9.0.0"
  }
}

# .npmrc — pnpm configuration
strict-peer-dependencies=true
auto-install-peers=true
shamefully-hoist=false
link-workspace-packages=true
prefer-workspace-packages=true

The --filter '...[origin/main]' syntax is particularly powerful — it runs tests only in packages that have changed since the main branch, dramatically reducing CI time in large monorepos.

Security Comparison

Security is a non-negotiable consideration for any dependency management tool. Each manager approaches it differently.

npm includes npm audit which checks your dependency tree against the GitHub Advisory Database. Since npm v8, it also supports npm audit signatures to verify package provenance. The package-lock.json records integrity hashes (SHA-512) for every package.

Yarn Berry supports yarn npm audit and adds a unique feature: yarn constraints, which let you write Prolog rules to enforce policies across your entire workspace (e.g., “no package may depend on lodash below v4.17.21”). Yarn PnP’s zip-based storage also makes it harder for post-install scripts to tamper with other packages.

pnpm provides pnpm audit backed by the same advisory database. Its strict node_modules structure is inherently more secure because packages cannot access undeclared dependencies, reducing the attack surface for dependency confusion attacks. pnpm also supports the .pnpmfile.cjs hook file where you can intercept and modify package metadata before installation — useful for patching known vulnerabilities without waiting for upstream fixes.

For teams managing infrastructure with Docker, containerized builds add another security layer. Our Docker for web developers guide explains how to create minimal production images that exclude development dependencies entirely.

Migration Guide: Moving to pnpm

If you have decided that pnpm’s performance and strictness benefits justify a switch, migration from npm or Yarn is straightforward. The following script automates the most common migration steps:

#!/bin/bash
# migrate-to-pnpm.sh — Automated migration from npm/Yarn to pnpm
# Usage: chmod +x migrate-to-pnpm.sh && ./migrate-to-pnpm.sh

set -euo pipefail

echo "=== JavaScript Package Manager Migration to pnpm ==="
echo ""

# Detect current package manager
if [ -f "yarn.lock" ]; then
    SOURCE="yarn"
    echo "[1/7] Detected Yarn project (yarn.lock found)"
elif [ -f "package-lock.json" ]; then
    SOURCE="npm"
    echo "[1/7] Detected npm project (package-lock.json found)"
else
    echo "Error: No lockfile found. Run this from your project root."
    exit 1
fi

# Check pnpm is installed
if ! command -v pnpm &> /dev/null; then
    echo "[2/7] Installing pnpm via corepack..."
    corepack enable
    corepack prepare pnpm@latest --activate
else
    echo "[2/7] pnpm $(pnpm --version) is already installed"
fi

# Back up existing files
echo "[3/7] Backing up current lockfile and node_modules..."
BACKUP_DIR=".migration-backup-$(date +%Y%m%d%H%M%S)"
mkdir -p "$BACKUP_DIR"
[ -f "yarn.lock" ] && cp yarn.lock "$BACKUP_DIR/"
[ -f "package-lock.json" ] && cp package-lock.json "$BACKUP_DIR/"
[ -f ".npmrc" ] && cp .npmrc "$BACKUP_DIR/"

# Remove old node_modules and lockfiles
echo "[4/7] Cleaning old artifacts..."
rm -rf node_modules
rm -f yarn.lock package-lock.json

# Create pnpm configuration
echo "[5/7] Creating .npmrc with recommended pnpm settings..."
cat > .npmrc << 'EOF'
# pnpm configuration
strict-peer-dependencies=true
auto-install-peers=true
shamefully-hoist=false
resolution-mode=highest
EOF

# Import and install
echo "[6/7] Running pnpm install (generating pnpm-lock.yaml)..."
pnpm install

# Update package.json scripts if needed
echo "[7/7] Adding packageManager field to package.json..."
PNPM_VERSION=$(pnpm --version)
node -e "
const pkg = require('./package.json');
pkg.packageManager = 'pnpm@$PNPM_VERSION';
require('fs').writeFileSync('package.json', JSON.stringify(pkg, null, 2) + '\n');
"

echo ""
echo "=== Migration Complete ==="
echo "Backup saved to: $BACKUP_DIR/"
echo ""
echo "Next steps:"
echo "  1. Run 'pnpm test' to verify everything works"
echo "  2. Update CI/CD configs to use pnpm (see pnpm.io/continuous-integration)"
echo "  3. Add 'pnpm-lock.yaml' to version control"
echo "  4. Update your .gitignore if needed"
echo "  5. Commit changes: git add -A && git commit -m 'chore: migrate to pnpm'"

After migration, run your full test suite and build pipeline to verify compatibility. Some packages with post-install scripts or native bindings may need the shamefully-hoist=true setting temporarily while you resolve strict-mode issues. The goal should be to operate with shamefully-hoist=false for maximum correctness.

Feature-by-Feature Comparison

The table below summarizes the practical differences across the features that matter most to working developers in 2025.

Feature	npm v10	Yarn Berry	pnpm v9
Ships with Node.js	Yes	Via Corepack	Via Corepack
Lockfile	package-lock.json	yarn.lock	pnpm-lock.yaml
Disk efficiency	Low (copies per project)	High (PnP) / Low (node_modules)	Excellent (content-addressable store)
Phantom dependency prevention	No	Yes (PnP only)	Yes (always)
Workspace support	Basic	Advanced	Advanced
Workspace filtering	Limited	Good	Excellent
Plug'n'Play (no node_modules)	No	Yes (default in Berry)	No
Patch protocol	No	yarn patch	pnpm patch
Side-effects cache	No	No	Yes
Overrides/resolutions	overrides field	resolutions field	pnpm.overrides field
Catalogs (shared versions)	No	No	Yes (v9+)
License checking	Third-party only	Built-in	pnpm licenses list
Ecosystem compatibility	Universal	PnP: partial / node_modules: full	Near-universal

When to Use Each Package Manager

There is no universally best package manager — the right choice depends on your team's priorities and constraints.

Choose npm When

• You want zero setup overhead. npm is there when you install Node. For tutorials, prototypes, or quick scripts, this is hard to beat.
• Your team has limited tooling experience. npm has the most documentation, the largest community, and the highest chance of getting help on Stack Overflow.
• You work in regulated environments where adding third-party tools to the build chain requires approval processes.

Choose Yarn Berry When

• You want PnP for maximum speed on warm installs. If your workflow involves frequent branch switching with different dependency trees, Yarn PnP's near-instant installs are compelling.
• You need workspace constraints. Yarn's Prolog-based constraint system is unique and powerful for enforcing policies across large monorepos.
• Your project already uses Yarn and migration to pnpm would bring negligible benefits for significant effort.

Choose pnpm When

• Disk space matters. If you work on multiple JavaScript projects simultaneously, pnpm's content-addressable store saves gigabytes of disk space.
• You want strict correctness. pnpm's non-flat node_modules structure catches phantom dependency issues that cause production bugs.
• You manage monorepos. pnpm's filtering, workspace protocol support, and catalogs make it the strongest monorepo tool among the three.
• CI/CD cost is a concern. pnpm's cold-install speed and efficient caching reduce pipeline duration and compute costs.

Teams managing complex JavaScript projects should also consider establishing consistent coding standards across their codebase. Our ESLint and Prettier code quality guide pairs well with any package manager choice.

pnpm Adoption in 2025: Who Uses It?

pnpm's adoption has accelerated dramatically. Major projects and companies using pnpm in production include Vue.js, Vite, SvelteKit, Prisma, Vercel's Turborepo, and Microsoft's Rush stack. The Vue ecosystem's full migration to pnpm workspaces was a significant endorsement that pushed many teams to evaluate the switch.

According to the State of JS 2024 survey, pnpm usage grew from 21% in 2022 to 44% in 2024, making it the fastest-growing package manager by adoption rate. npm remains the most used at 89% (because it ships with Node), while Yarn's usage has stabilized around 35%.

For teams evaluating modern JavaScript runtimes alongside package managers, it is worth noting that Bun includes its own built-in package manager that claims even faster install times than pnpm. However, Bun's package manager is not yet mature enough for production use in most enterprise contexts.

Version Control and Lockfile Strategy

Regardless of which package manager you choose, always commit your lockfile to version control. The lockfile ensures every team member and CI server installs the exact same dependency versions. Without it, "works on my machine" bugs are inevitable.

Manager	Commit to Git	Do NOT Commit
npm	package-lock.json	node_modules/
Yarn Berry (PnP)	yarn.lock, .pnp.cjs, .yarn/cache/	.yarn/unplugged/ (sometimes)
Yarn Berry (node_modules)	yarn.lock	node_modules/
pnpm	pnpm-lock.yaml	node_modules/

Note that Yarn PnP's "zero-install" approach (committing the cache) is controversial. It bloats your repository significantly but enables truly offline, instant installs with no CI caching configuration needed.

Practical Recommendations for Teams

If you are starting a new project in 2025 and have no strong preference, pnpm is the recommended default. Its combination of speed, disk efficiency, and strict correctness addresses the most common pain points JavaScript developers face. The learning curve is minimal — most npm commands work identically with pnpm (just replace npm with pnpm).

For existing projects, consider the migration cost carefully. If npm or Yarn is working fine and your team is productive, the performance gains from switching may not justify the disruption. Focus migration efforts on monorepos and CI-heavy projects where pnpm's advantages compound.

If your team manages complex web projects and wants expert guidance on tooling decisions like package manager selection, Toimi specializes in helping development teams optimize their workflows and infrastructure. For project management that integrates with your development pipeline, Taskee provides tools designed specifically for technical teams.

Frequently Asked Questions