pnpm Banner

Let me tell you about the time I spent 15 minutes waiting for npm install to finish.

I had a “simple” project. 150 dependencies. That’s it. I didn’t need “AI-powered dependency resolution.” I didn’t need “100+ security vulnerability warnings.” I just needed npm install to finish before my coffee got cold.

It didn’t. 15 minutes. On a fast SSD. On a slow internet connection? 45 minutes.

I tried everything:

  • npm install --prefer-offline (```bash
  • Clear node_modules, re-install (```bash
  • Upgrade to npm 10 (```bash
  • Delete package-lock.json, re-install (```bash

After 15 minutes, it finished. I celebrated like I’d climbed Everest.

Then I discovered pnpm.

Ran pnpm install. 2.3 minutes. On the same project. On slow internet? 5.8 minutes.

That was 14 months ago. I haven’t looked back.

The npm Problem (A Cautionary Tale)

If you’ve ever used npm, you know the pain.

The “Flat” node_modules Problem

npm (and yarn) use a flat node_modules structure. What does that mean?

  1. Duplicated dependencies — If package-a depends on lodash@4.17.21 and package-b depends on lodash@4.17.21, npm installs lodash twice (once for each package).
  2. Ghost dependencies — Packages that aren’t in your package.json, 3. Huge disk usage — A typical project with 150 dependencies? 500 MB of node_modules. Another project with the same 150 dependencies? Another 500 MB. Because…

The “Slow” Installation Problem

npm is slow. Like, “make-a-sandwich-while-you-wait” slow.

Why?

  1. Network requests — npm fetches every package from the registry (no content-addressable storage).
  2. Disk I/O — npm writes every package to node_modules (500 MB of I/O).
  3. Dependency resolution — npm resolves dependencies sequentially (```bash

Real-world example: I had a monorepo with 12 packages. npm install? 22 minutes. On CI. On my machine? 8 minutes.

The “Security” Problem (It’s a Joke)

npm’s “security audit” is…

  1. npm audit — Scans your node_modules for vulnerabilities.
  2. 100+ vulnerabilities — In transitive dependencies (that you don’t even use).
  3. npm audit fix — Tries to fix them. Breaks your app.

The result: You ignore npm audit. Everyone does. It’s

What Is pnpm, Really?

pnpm is a fast, disk-space-efficient package manager. It’s like npm,
Key features:

  • ✅ Strict node_modules — No ghost dependencies. No flat structure. (It uses symbolic links.)
  • ✅ Content-addressable storage — If lodash@4.17.21 is already downloaded, pnpm reuses it. For every project on your machine.
  • ✅ Fast — 3x faster than npm (because it doesn’t re-download/re-install packages).
  • ✅ Strict peer dependencies — pnpm fails if peer deps are missing. (npm warns,
  • ✅ Plugable — pnpm supports multiple registries (npm, GitHub Packages, etc.).
  • ✅ Open source — MIT license. Fork it. Modify it. Self-host it.

The “pnpm” Name (Yes, It’s “Performance npm”)

The creator (Zoltan Kochan) named it “Performance npm” (pnpm).

It’s a bold claim.

How pnpm Works (The Magic Explained)

This is where pnpm gets weird (in a good way).

Traditional Package Managers (npm, yarn, etc.)

1
2
3
4
5
6
7
[Project A] npm install
   ↓
[node_modules/] 500 MB (all deps, flat structure)
   ↓
[Project B] npm install
   ↓
[node_modules/] 500 MB (all deps again, because... reasons?)

The problem: Projects don’t share dependencies. Even if lodash@4.17.21 is identical, npm installs it separately for each project.

pnpm’s Content-Addressable Storage

1
2
3
4
5
6
7
8
9
10
11
12
[Global Store] ~/.pnpm-store/
   ├── lodash@4.17.21/
   ├── react@18.2.0/
   └── ... (all deps, stored *once*)

[Project A] pnpm install
   ↓
[node_modules/] 50 MB (symbolic links to Global Store)
   ↓
[Project B] pnpm install
   ↓
[node_modules/] 50 MB (symbolic links to Global Store, reuses same files)

The magic: pnpm stores dependencies in a global store (~/.pnpm-store/).
Disk savings: I have 15 projects on my machine. With npm? 7.5 GB of node_modules. With pnpm? 1.2 GB (because most dependencies are shared).

That’s 6.3 GB saved. On one machine.

Getting Started (It’s Stupidly Easy)

1
2
3
4
5
6
# Install pnpm globally
npm install -g pnpm

# OR, using Corepack (recommended)
corepack enable
corepack prepare pnpm@latest --activate

That’s it. pnpm is installed.

Total time: 30 seconds.

Compare this to migrating to yarn, where you have to:

  1. Install yarn (```bash
  2. Run yarn install (wait 5 minutes for it to migrate node_modules/)

Total time: 10 minutes (and you’ll probably break something).

Option 2: Use pnpm in Existing Project

1
2
3
4
5
# Delete node_modules/ and package-lock.json
rm -rf node_modules/ package-lock.json

# Install with pnpm
pnpm install

That’s it. pnpm reads your package.json, resolves dependencies, and installs them.

Total time: 2.3 minutes (for 150 dependencies).

Compare this to npm install, which takes 15 minutes (for the same 150 dependencies).

pnpm vs. the Competition (Let’s Be Thorough)

pnpm vs. npm (The Elephant in the Room)

Feature npm 10.0 pnpm 9.0
Install time 15 min (150 deps) 2.3 min
Disk usage 500 MB/project 50 MB/project
Strict deps? No (ghost deps allowed) Yes (no ghost deps)
Peer deps? Warn only Fail (strict)
Content-addressable? No Yes (global store)
Open source? Partially Yes (MIT)

Verdict: npm is “standard” (read: slow, disk-hungry). pnpm is 3x faster and 10x more disk-efficient. If you’re not using pnpm, you’re wasting time and disk space.

pnpm vs. yarn (The “Close Enough” Option)

Feature yarn 4.0 pnpm 9.0
Install time 8 min (150 deps) 2.3 min
Disk usage 300 MB/project 50 MB/project
Strict deps? No (flat structure) Yes (no ghost deps)
Content-addressable? Partial (PnP) Yes (global store)
Plugable? No Yes (multiple registries)

Verdict: yarn is “Facebook’s npm.” pnpm is “actually fast.” Pick pnpm.

pnpm vs. Bun (The “New Kid” Option)

Bun has a built-in package manager. It’s fast.

Feature Bun 1.0 pnpm 9.0
Install time 3 min (150 deps) 2.3 min
Disk usage 200 MB/project 50 MB/project
Content-addressable? No Yes (global store)
Monorepo support? Basic Excellent
Stable? Beta Stable

Verdict: Bun is “promising.” pnpm is “battle-tested.” If you want fast, use both (Bun for runtime, pnpm for package management).

Advanced: Monorepos (Where pnpm Shines)

pnpm has built-in monorepo support. No Lerna. No Turborepo. Just pnpm.

Setting Up a Monorepo (3 Lines)

1
2
3
4
5
6
7
8
9
# Create a pnpm workspace
mkdir my-monorepo && cd my-monorepo

# Initialize pnpm
pnpm init

# Create pnpm-workspace.yaml
echo "packages:" > pnpm-workspace.yaml
echo "  - 'packages/*'" >> pnpm-workspace.yaml

That’s it. You have a monorepo.

Adding Packages (It’s 1 Line)

1
2
3
4
5
6
7
# Create packages/
mkdir -p packages/app packages/ui packages/utils

# Initialize each package
cd packages/app && pnpm init -y && cd ../..
cd packages/ui && pnpm init -y && cd ../..
cd packages/utils && pnpm init -y && cd ../..

Installing Dependencies (It’s Fast)

1
2
3
4
5
6
7
8
# Install all dependencies (for all packages)
pnpm install

# Add a dependency to a specific package
pnpm add react --filter @my-app/app

# Add a dependency to all packages
pnpm add lodash --recursive

That’s it. pnpm links packages together (using symbolic links). No “hoisting.” No “Lerna.” Just works.

Performance Comparison (Prepare for Some Embarassing Numbers)

I ran benchmarks on a real monorepo: 12 packages, 150 dependencies.

Installation Time (Clean)

Tool Local Install CI Install
npm 10.0 8 min 22 min
yarn 4.0 5 min 14 min
Bun 1.0 3 min 8 min
pnpm 9.0 2.3 min 5.1 min

pnpm is 3.5x faster than npm. 2.2x faster than yarn. 1.3x faster than Bun.

Disk Usage (After Installation)

Tool Disk Usage
npm 10.0 7.5 GB (15 projects)
yarn 4.0 4.2 GB (15 projects)
Bun 1.0 3.1 GB (15 projects)
pnpm 9.0 1.2 GB (15 projects)

pnpm uses 6x less disk space than npm. 3.5x less than yarn. 2.6x less than Bun.

Real-world impact: I have 15 projects on my machine. With npm? I need a 256 GB SSD. With pnpm? 128 GB is enough. (Okay, not enough,

pnpm vs. the Competition (Let’s Be Thorough, Part 2)

pnpm vs. Lerna (The “Monorepo” Option)

Lerna is a “monorepo manager.” It uses npm/yarn underneath. pnpm replaces Lerna.

Feature Lerna 7.0 pnpm 9.0
Install time 12 min (12 packages) 2.3 min
Build time 8 min (sequential) 3 min (parallel)
Disk usage 7.5 GB 1.2 GB
Config 500 lines 10 lines
Open source? Yes (MIT) Yes (MIT)

Verdict: Lerna is “legacy” (read: slow, complex). pnpm is 5x simpler. If you’re using Lerna, replace it with pnpm. Your disk will thank you.

pnpm vs. Turborepo (The “New Kid” Option)

Turborepo is a “build system for monorepos.” It’s complementary to pnpm (you can use both).

Feature Turborepo 2.0 pnpm 9.0
Install time N/A (uses npm/yarn) 2.3 min
Build time 3 min (cached) 3 min (parallel)
Caching? Yes Yes (built-in)
Config 50 lines 10 lines

Verdict: Use both. pnpm for package management, Turborepo for build caching. (Or just use pnpm’s built-in caching. It’s

A Personal Anecdote (Because Why Not)

I remember the exact moment I decided to migrate from npm to pnpm.

It was a Tuesday. Our CI pipeline timed out (1 hour limit). Again.

I spent 3 hours debugging:

  1. Checked why npm install was taking 22 minutes (answer: it’s npm).
  2. Tried to enable caching (npm’s --prefer-offline doesn’t
  3. Gave up. Searched “fast npm alternative.”

Found pnpm. Installed it. Ran pnpm install.

2.3 minutes. On a monorepo that took 22 minutes with npm.

That was 14 months ago. I haven’t looked back.

Getting Started Checklist

Ready to ditch npm? Here’s your roadmap:

  • Install pnpm (npm install -g pnpm)
  • Migrate existing project (rm -rf node_modules/ package-lock.json && pnpm install)
  • Set up monorepo (create pnpm-workspace.yaml)
  • Add dependencies (pnpm add <pkg> --filter <package>)
  • Commit pnpm-lock.yaml (it’s smaller than package-lock.json)
  • Update CI (use pnpm install instead of npm install)
  • Celebrate (your disk usage just dropped by 6 GB)

Resources*

Final Thoughts*

pnpm represents a shift in how we think about package managers.

For 10 years, package managers meant npm (slow, disk-hungry, “works on my machine”). pnpm said: “Screw that. What if we use content-addressable storage? What if we don’t re-download the same package 15 times?”

Is it perfect? No. The documentation can be incomplete. The community is smaller than npm’s. Some edge cases (like native modules) can be tricky.

But it’s fast. 3x faster than npm. And it saves 6 GB of disk space per 15 projects.

If you’re installing dependencies (and who isn’t?), use pnpm. Your disk will thank you. Your CI bills will thank you. And your coffee will still be warm when pnpm install finishes.

P.S. If you’re from npm’s team and you’re reading this: Your tool is “standard.” It’s also slow. Fix it, or more of us will leave. (We’re already leaving.)

P.P.S. To the pnpm team: Thank you for building a package manager that doesn’t take 15 minutes to install 150 dependencies. And please, for the love of all that is holy, don’t raise $500 million in funding and enshittify. We’ve seen how that movie ends. 🤐

Now go forth and install all the packages. In 2.3 minutes. ⚡