pnpm 10 vs npm 11 vs Yarn 4 in 2026

TL;DR

pnpm 10 remains the fastest and most disk-efficient package manager in 2026 — 3.4× faster than npm on cold installs and uses 75% less disk space. npm 11 improves security meaningfully but is still the slowest of the three. Yarn 4 (Berry) is the best choice for large monorepos using Plug'n'Play, but its node_modules mode performance doesn't justify the switch from pnpm. For greenfield Node.js projects in 2026: start with pnpm 10.

Key Takeaways

• pnpm 10 installs in 4.2s cold vs npm 11's 14.3s — a 3.4× speed advantage that compounds at scale
• pnpm 10's security defaults are now the strictest — dependency lifecycle scripts are disabled by default since v10, in direct response to supply chain attacks
• Yarn 4 is 3× faster than Yarn 3 thanks to a new metadata cache, making Berry finally competitive for CI pipelines
• Disk usage: pnpm 124MB vs npm 487MB for a 200-dependency project — pnpm's global content store eliminates duplication across projects
• npm 11 ships with Node.js 24 — trusted publishing and improved git security defaults are its standout additions
• All three support workspaces — monorepo support is table-stakes; the differentiator is performance and security posture

---

Why This Still Matters in 2026

The npm vs Yarn debate started in 2016. With Bun's package manager now in the picture and pnpm passing 10 million weekly downloads, you'd think the choice would be settled. It isn't — and the right answer depends heavily on whether you're running a monorepo, how much you care about supply chain security, and how much CI time costs your team.

pnpm 10 shipped in January 2025 with what may be its most consequential change: lifecycle scripts are now blocked by default. This came directly after the Rspack npm supply chain attack, where a compromised postinstall script distributed cryptomining malware to thousands of projects. npm and Yarn haven't followed suit — as of March 2026, they still execute lifecycle scripts on install without explicit approval.

npm 11 (bundled with Node.js 24) brings meaningful security improvements of its own: bulk trusted publishing via OIDC and a new --allow-git flag that gives explicit control over git dependency behavior. Yarn 4 focused on performance and ergonomics after Berry's rough reception — and largely succeeded.

---

Install Speed Benchmarks (2026)

Testing on a React + TypeScript starter with 50 direct dependencies (~400 total packages):

Cold Install (no cache, no lockfile)

Package Manager	Cold Install Time	vs npm
pnpm 10.x	4.2s	3.4× faster
Yarn 4 (node_modules)	6.8s	2.1× faster
npm 11	14.3s	baseline
Yarn 4 (PnP)	3.1s	4.6× faster

Yarn 4 in Plug'n'Play mode is technically the fastest — but PnP requires ecosystem compatibility checks and IDE configuration that pnpm's standard node_modules mode doesn't. For real-world projects, pnpm 10's 4.2s is the practical winner for node_modules setups.

Warm Install (with cache and lockfile)

Package Manager	Warm Install Time
pnpm 10.x	755ms
Yarn 4 (node_modules)	1.2s
npm 11	4.8s

npm 11 improved significantly over npm 10 on warm installs, but pnpm's global content-addressed store — where packages are stored once and hard-linked into each project — makes repeat installs almost instant.

CI Pipeline Impact

For a team running 100 CI jobs/day on a medium-sized monorepo:

• npm 11 warm install: ~4.8s × 100 = ~8 minutes of install time/day
• pnpm 10 warm install: ~755ms × 100 = ~1.3 minutes of install time/day

That's 6.7 minutes of CI time saved daily — roughly 40 minutes/week — just from switching to pnpm. At $0.008/minute for typical CI compute, that's ~$19/month in compute savings.

---

Disk Usage

pnpm's content-addressable store is its most compelling advantage for developer machines:

Package Manager	node_modules size (200 deps)	Global cache
npm 11	487 MB	Separate cache dir
Yarn 4 (node_modules)	502 MB	Shared mirror cache
pnpm 10	124 MB	Global content store (shared across projects)

npm and Yarn install a complete copy of each dependency into each project's node_modules. pnpm stores each package version exactly once in a global content store (~/.pnpm-store) and creates hard links from project node_modules to the store.

If you work on 5 projects all using React 19 and TypeScript 5, npm stores React 19 and TypeScript 5 5 times. pnpm stores them once.

For a developer working on 10 Node.js projects simultaneously, pnpm can save 3-4GB of disk space compared to npm or Yarn in node_modules mode.

---

pnpm 10: The Security Overhaul

pnpm 10's most significant change is the default block on lifecycle scripts — preinstall, install, postinstall, prepare, and prepublishOnly scripts in dependencies no longer run automatically.

Before v10, npm install would silently execute postinstall scripts from every dependency in your tree — including transitive ones you'd never heard of. This is the vector that the Rspack supply chain attack exploited.

The New onlyBuiltDependencies Field

To allow specific packages to run their build scripts, you explicitly list them in package.json:

{
  "pnpm": {
    "onlyBuiltDependencies": [
      "esbuild",
      "sharp",
      "@prisma/client"
    ]
  }
}

If a dependency needs a build script that isn't listed, pnpm fails loudly — no silent security holes. The allowBuilds setting in pnpm v10.26+ replaces onlyBuiltDependencies with a more flexible map:

{
  "pnpm": {
    "allowBuilds": {
      "esbuild": true,
      "sharp": true,
      "evil-package": false
    }
  }
}

This is a breaking change from pnpm 9. If you're upgrading, run pnpm install first and check which packages trigger the new warnings — most projects need to whitelist fewer than 5 packages.

pnpm 10 Monorepo: Graph-Hashed Virtual Store

pnpm 10.12 introduced a central, graph-hashed virtual store for monorepos. When multiple workspace packages share the same dependency graph, pnpm now deduplicates the entire dependency tree — not just individual packages. On large monorepos (50+ packages, thousands of total dependencies), warm installs can drop below 500ms.

---

npm 11: Conservative but More Secure

npm 11 ships as the default package manager with Node.js 24. Its philosophy hasn't changed: broad compatibility, minimal surprises, and slow-but-intentional security improvements.

Trusted Publishing via OIDC

npm 11's standout feature is bulk OIDC trusted publishing. Teams can now configure trusted publishing for entire package scopes via npm trust, instead of configuring each package individually. This reduces the friction that previously caused teams to skip trusted publishing entirely.

The --allow-git Flag

A subtle but meaningful security addition: git dependencies can include .npmrc files that override the git executable path. The new --allow-git flag defaults to all for backward compatibility but gives teams the option to lock down git dependency behavior:

npm install --allow-git=none

Using --allow-git=none is the safest option unless you specifically need git dependencies — which most production applications don't.

What npm 11 Doesn't Fix

npm 11 still runs lifecycle scripts by default. After the Rspack incident, this looks increasingly like a calculated risk versus a deliberate security stance. The ignore-scripts flag exists but requires developers to remember to use it — an opt-in security control that pnpm 10 made opt-out.

---

Yarn 4 (Berry): PnP or Bust

Yarn 4 is a fundamentally different product depending on how you use it.

In Plug'n'Play mode, Yarn 4 is fast, deterministic, and produces zero-install workflows where the .yarn/cache is committed to git and no node_modules directory is needed. CI runs without an install step. This is a genuine advantage for teams with long CI installs — though it requires all dependencies to support PnP (most popular packages do in 2026, but edge cases exist).

In node_modules mode (Yarn 4 without PnP), performance is better than Yarn 3 but doesn't justify switching from pnpm unless you're already invested in the Yarn ecosystem.

Yarn 4's New Constraints Engine

Yarn 4 replaces Prolog-based constraints with a JavaScript (optional TypeScript) engine. For monorepos enforcing version consistency across packages, this matters:

// .yarn/constraints.js
export default defineConfig({
  async constraints({ Yarn }) {
    for (const dep of Yarn.dependencies()) {
      if (dep.ident === "react") {
        dep.update("^19.0.0");
      }
    }
  }
});

This is more accessible than Prolog constraints and meaningfully improves the monorepo governance story for large teams.

---

Monorepo Comparison

Feature	pnpm 10	npm 11	Yarn 4
Workspace protocol	✅ workspace:*	✅ workspace:*	✅ workspace:*
Hoisting control	Strict by default	Loose by default	Configurable
Phantom deps blocked	✅ Yes	❌ No	✅ (PnP)
Constraints engine	Basic catalog	❌ None	✅ JS-based
Parallel install	✅	✅	✅
Zero-installs	❌	❌	✅ (PnP)
Graph-hashed store	✅ v10.12+	❌	❌

pnpm 10's strict hoisting blocks phantom dependencies — packages you can import because a dependency happens to include them, but aren't in your package.json. npm's loose hoisting makes phantom dependencies a silent source of production bugs when dependency versions change.

---

Migration Guide

From npm to pnpm 10

# Install pnpm
npm install -g pnpm

# Import existing package-lock.json
pnpm import

# Install (will prompt for onlyBuiltDependencies)
pnpm install

# Add to package.json
echo '{"packageManager": "pnpm@10.x"}' >> package.json

Check pnpm-lock.yaml into git — it replaces package-lock.json.

Upgrading pnpm 9 → 10

The breaking change is lifecycle scripts. After upgrading:

pnpm install 2>&1 | grep "blocked"

This shows which packages tried to run scripts. Add them to pnpm.onlyBuiltDependencies if they're legitimate (esbuild, sharp, native addons).

---

Verdict: Which Should You Use?

pnpm 10 — Default choice for new projects. Fastest, most disk-efficient, and now the most secure by default. The onlyBuiltDependencies migration is a one-time 10-minute task.

Yarn 4 with PnP — Best for teams who can commit to zero-installs and want the fastest CI without a caching layer. Requires PnP compatibility audit for your dependency tree.

npm 11 — Use when you can't control which package manager your team uses (e.g., onboarding environments) or when maximal compatibility with the npm ecosystem is the priority. It's not fast, but it's never wrong.

---

Methodology

• Install benchmarks from pnpm.io/benchmarks and the 2026 package manager showdown on Dev.to (200-dependency React + TypeScript project, averaged over 5 runs)
• Disk usage measurements on macOS Sonoma with Node.js 24 LTS
• Security analysis from Socket.dev and pnpm GitHub Discussions
• All data as of March 2026

---

Related: Best JavaScript Package Managers 2026, Bun Install vs pnpm vs Yarn Berry, pnpm Workspaces vs Nx vs Turborepo Monorepo Tools 2026. See also the npm packages directory for download trend comparisons across the ecosystem.