pnpm is a fast, disk-efficient package manager for Node.js. It installs dependencies up to 3× faster than npm, uses up to 80% less disk space across multiple projects, and enforces strict dependency resolution by default. pnpm is fully compatible with the npm registry and is used in production by teams behind Vercel, Microsoft, Vite, Vue, Astro, and many others.

What Is pnpm?

pnpm – short for „performant npm” – is an open-source, MIT-licensed JavaScript package manager created by Zoltan Kochan and maintained by a community of contributors. Unlike npm and Yarn, which copy every dependency into each project’s node_modules, pnpm stores every version of every package once in a global content-addressable store on your disk and then uses hard links and symlinks to make those packages available to each project.

The result: faster installs, dramatically smaller disk usage, and a stricter dependency tree that catches phantom-dependency bugs before they hit production.

Key facts:

  • Open-source, MIT-licensed (github.com/pnpm/pnpm)
  • ~250k GitHub stars and 30M+ weekly npm downloads
  • Compatible with the npm registry and most package.json commands
  • Used by major projects: Vercel, Microsoft (Rush, FluentUI), Vite, Vue, Astro, Prisma, Storybook
  • Latest stable: pnpm 9 / 10 (check pnpm.io for the current version)
  • Has built-in monorepo / workspace support out of the box
  • Installable via Corepack (corepack enable) — no global npm install needed

pnpm vs npm vs Yarn vs Bun – Side-by-Side

Aspect npm Yarn pnpm Bun
Install speed (cold cache) Baseline ~1.3× faster than npm ~2–3× faster than npm ~10–25× faster than npm (per Bun benchmarks)
Install speed (warm cache) Baseline Similar to npm 2× faster (hard links instead of copies) Fastest
Disk usage (multiple projects) High — each project copies all deps High — same as npm Low — single global store, hard-linked into projects Low — also uses a global cache
node_modules structure Flat (hoisted) Flat (hoisted) or Yarn Berry’s PnP Symlinked, non-flat — strict Flat (hoisted)
Lockfile package-lock.json yarn.lock pnpm-lock.yaml bun.lockb (binary)
Phantom dependencies Allowed (you can import packages you didn’t declare) Allowed Blocked by default Allowed
Workspaces / monorepo Yes (workspaces) Yes Yes — first-class, very mature Yes
Bundled with runtime Yes (ships with Node.js) No No Yes (Bun is also a runtime)
Production maturity Maximum High High — widely used in production Newer — still maturing for some workflows

In short: pick npm for default compatibility and zero install. Pick Yarn if you’re locked into a Yarn-based codebase. Pick pnpm if you want a faster, leaner, stricter package manager for new projects or monorepos. Pick Bun if you want the fastest installer and don’t mind running on the Bun runtime.

For independently verified benchmarks, see the official pnpm benchmarks at https://pnpm.io/benchmarks.

How pnpm works (and why it’s faster)

Traditional package managers like npm and Yarn Classic copy every dependency into each project’s node_modules folder. If you have 50 projects, you have 50 copies of React on disk.

pnpm takes a different approach:

  1. Every package version is downloaded once to a global content-addressable store, typically at ~/.local/share/pnpm/store (Linux/macOS) or %LOCALAPPDATA%\pnpm\store (Windows).
  2. When you run pnpm install, pnpm hard-links files from the global store into your project’s node_modules/.pnpm folder.
  3. pnpm then creates a symlinked, isolated node_modules tree so each project sees only the dependencies it explicitly declared in package.json.

This gives you three concrete wins:

  • Speed – hard linking is almost instant compared to copying gigabytes of files
  • Disk space – 50 projects with React installed share a single React on disk
  • Correctness – you can no longer accidentally import a package you didn’t declare as a dependency (a class of bug npm and Yarn Classic both allow)

How much disk space does pnpm actually save?

A real-world example: a Next.js project with ~1,000 transitive dependencies takes roughly 250 MB on npm and roughly 50 MB on pnpm – about 80% smaller. With 10 such projects on your machine, that’s the difference between ~2.5 GB and ~250 MB plus a shared store.

The savings scale: the more projects you have, the bigger the win, because pnpm only stores each unique file once globally regardless of how many projects use it.

How to Install pnpm

The recommended way to install pnpm in 2026 is through Corepack, which ships with Node.js:

corepack enable
corepack prepare pnpm@latest --activateCode language: CSS (css)

Alternatively, you can install pnpm directly:

# Via npm
npm install -g pnpm

# Via Homebrew (macOS)
brew install pnpm

# Via standalone script (no Node required)
curl -fsSL https://get.pnpm.io/install.sh | sh -Code language: PHP (php)

Verify the installation:

pnpm --version

pnpm Quick Start

Once installed, the day-to-day pnpm commands are nearly identical to npm:

# Initialize a new project
pnpm init

# Install all dependencies from package.json
pnpm install

# Add a runtime dependency
pnpm add react

# Add a dev dependency
pnpm add -D vitest

# Remove a dependency
pnpm remove lodash

# Run a script from package.json
pnpm run build

# Shortcut: pnpm <script> works for most scripts
pnpm test

# Run a one-off binary (like npx)
pnpm dlx create-vite my-appCode language: PHP (php)

If you’ve used npm or Yarn, the muscle memory transfers — there is no real learning curve.

pnpm with Monorepos (Workspaces)

pnpm has first-class monorepo support and is the package manager of choice for many large open-source monorepos, including Vite, Vue, Astro, Prisma, Element Plus, and NextAuth.

Set up a workspace by creating a pnpm-workspace.yaml file in your repository root:

packages:
  - "apps/*"
  - "packages/*"Code language: JavaScript (javascript)

Then you can:

  • install dependencies for individual packages,
  • share internal packages using the workspace:* protocol,
  • run scripts across all packages with pnpm -r run build,
  • benefit from a single hard-linked dependency store across the entire monorepo.

For a deeper dive into monorepo architecture and workflows, see our guide:

Monorepo Development – Is It Worth It?

Real-world impact: A CI Pipeline Case

„In one of our CI pipelines, switching from npm to pnpm reduced install times from around 20 minutes to about 9 minutes – cutting the slowest step of every deploy by more than half. The disk usage of our build runners dropped by roughly two-thirds at the same time.”

Krystian Juraszek, Senior Developer, fireup.pro

That kind of CI win compounds quickly. A team running 50 deploys a week saves roughly 9 hours of pipeline time per week and pays for the migration in days.

When to use pnpm (and when not to)

pnpm is a strong fit if you:

  • Start a new Node.js or TypeScript project
  • Run a monorepo or multi-package codebase
  • Want faster CI/CD pipelines
  • Care about disk usage on developer laptops or CI runners
  • Want strict dependency hygiene (no phantom imports)
  • Use modern bundlers (Vite, Next.js, Remix, Astro, Nuxt, SvelteKit)

pnpm is less of a fit if you:

  • Maintain a codebase locked into Yarn Berry’s PnP — switching is non-trivial
  • Use legacy tooling that hard-codes flat node_modules paths and can’t be configured
  • Need to support Node.js < 18 (older Node versions work but the install experience is degraded)
  • Are deeply invested in a Bun-based stack — at that point you’re already getting Bun’s installer

Need help speeding up your CI/CD or migrating to pnpm?

Migrating a single project to pnpm takes minutes. Migrating a monorepo with custom tooling, complex peer dependencies, or legacy CI configuration can take days. We’ve helped clients migrate Node.js and TypeScript codebases – including monorepos, custom CI pipelines, and Dockerized builds — to pnpm. If you want to speed up your pipelines without touching application code, talk to an expert: https://fireup.pro/lets-talk

Further reading on fireup.pro:

External references: