Best JavaScript Package Managers 2026
TL;DR
pnpm for monorepos and disk efficiency; npm for simplicity; Yarn Berry for Plug'n'Play. pnpm (~12M weekly downloads) uses a content-addressable store — install each package version once on your machine, hard-link everywhere. npm (~100M+ is built into Node.js, used everywhere. Yarn Berry (~6M downloads) with PnP eliminates node_modules entirely but has ecosystem compatibility issues. For new projects in 2026, pnpm is the technical winner; npm is the safe default.
Key Takeaways
- npm: ~100M+ downloads — built into Node.js, largest ecosystem, default for most
- pnpm: ~12M downloads — 2x faster installs, 70% less disk space, strictest resolution
- Yarn Berry: ~6M downloads — PnP mode eliminates node_modules; workspace support
- Bun: ~2M downloads — 3-5x faster than npm, all-in-one runtime+bundler+pm
- pnpm workspaces — best-in-class monorepo support with workspace protocol
The Package Manager Landscape in 2026
The JavaScript package manager space looks stable in 2026, but the defaults have quietly shifted. Two years ago, npm was the unquestioned default for new projects. Today, most opinionated project scaffolders (Turborepo, T3, most framework CLIs) either default to pnpm or ask which package manager you want. The question isn't "should I use npm" but "is there a reason not to switch to pnpm."
The performance case for switching is real: pnpm installs 2x faster and uses 70% less disk space than npm. The architectural reason is pnpm's content-addressable store: packages are stored once globally on your machine, regardless of how many projects use them. If five projects use React 18.2, your disk contains one copy of React 18.2, hard-linked into each project's node_modules. npm creates separate copies per project.
Understanding why the package managers differ helps you choose correctly. The differences aren't just speed — they reflect different philosophies about dependency resolution, strictness, and the fundamental question of whether node_modules should exist at all.
npm (The Standard)
# npm — built into Node.js, no install needed
npm install react react-dom
npm install -D typescript @types/react
# Workspaces
npm install --workspace=apps/web react
npm run build --workspace=apps/web
# Common flags
npm install --legacy-peer-deps # Fix peer dep conflicts
npm ci # Clean install from lockfile (CI)
npm audit # Security audit
npm outdated # List outdated packages
npm update # Update within semver ranges
// package.json — npm workspaces
{
"workspaces": ["apps/*", "packages/*"],
"scripts": {
"build": "npm run build --workspaces --if-present",
"test": "npm test --workspaces --if-present"
}
}
npm's strengths are ubiquity and zero setup cost. Every developer with Node.js has npm. Every CI environment has npm. Corporate environments with locked-down tooling have npm. There's no installation step, no configuration file to set up, no colleagues who don't know how to use it.
The package-lock.json lockfile is mature and reliable. npm ci (clean install from lockfile) is the right CI pattern — it installs exactly the locked versions without checking for updates, producing reproducible builds. npm's audit system integrates directly with the npm security advisory database.
npm workspaces, introduced in npm 7, enable basic monorepo support. The --workspaces flag runs commands across all workspace packages, and --workspace=apps/web targets specific packages. For small monorepos (2-3 packages), this is sufficient. For larger monorepos, pnpm workspaces provide better filtering, dependency visualization, and the workspace:* protocol for local package references.
npm's limitations are real: it's slower than alternatives, uses more disk space, and its node_modules structure allows "phantom dependencies" — packages that aren't listed in your dependencies but are accessible because they happen to be installed transitively. pnpm's strict mode prevents this.
pnpm (Recommended)
# Install pnpm
npm install -g pnpm
# or: curl -fsSL https://get.pnpm.io/install.sh | sh -
# pnpm commands (same API as npm)
pnpm install
pnpm add react react-dom
pnpm add -D typescript
pnpm remove lodash
# The magic: content-addressable store
# ~/.pnpm-store — packages stored ONCE, hard-linked
# node_modules/.pnpm — virtual store with flat deps
# pnpm-workspace.yaml — monorepo config
packages:
- 'apps/*'
- 'packages/*'
- '!**/test/**'
# pnpm workspace commands
pnpm --filter web install # Install deps for web only
pnpm --filter web build # Build web package
pnpm --filter '...web' build # Build web and its deps
pnpm --filter './packages/**' test # Test all packages
pnpm -r build # Recursive: build all
# pnpm workspace protocol
# In apps/web/package.json:
# "dependencies": { "@myrepo/ui": "workspace:*" }
# This links to the local package — no version pinning needed
# pnpm performance vs npm
# Fresh install (200 packages):
# npm: 45s
# pnpm: 22s (2x faster, ~70% less disk)
# yarn: 30s
# Cached install:
# npm: 15s
# pnpm: 5s (3x faster)
# yarn: 8s
# .npmrc — pnpm strict mode (prevents phantom dependencies)
shamefully-hoist=false # Don't hoist transitive deps to root
strict-peer-dependencies=true # Fail on peer dep conflicts
pnpm's phantom dependency prevention is worth understanding in depth. In npm, if package A depends on lodash, and your project depends on A, you can require('lodash') in your code and it will work — because npm's flat node_modules puts all transitive dependencies at the top level. This is a "phantom dependency": lodash isn't in your package.json, but you can use it.
The problem: if you later upgrade A to a version that no longer depends on lodash, your code breaks silently. pnpm prevents this by using a non-flat structure where only direct dependencies are accessible. Phantom dependency bugs caught during migration to pnpm are real issues you didn't know you had.
The workspace:* protocol is pnpm's most valuable monorepo feature. Instead of versioning local packages ("@myrepo/ui": "^1.2.3"), you reference them as "@myrepo/ui": "workspace:*" — meaning "use whatever version exists in the workspace." When publishing, pnpm automatically replaces workspace:* with the actual version. This eliminates the need to bump version numbers in dependent packages during development.
Yarn Berry (PnP)
# Yarn Berry — enable in project
yarn set version stable # Switch to Yarn Berry
# or: yarn set version berry
# .yarnrc.yml — created automatically
# .yarnrc.yml — Yarn Berry config
nodeLinker: pnp # Plug'n'Play (no node_modules)
# nodeLinker: node-modules # Traditional (if PnP compatibility issues)
yarnPath: .yarn/releases/yarn-4.x.y.cjs
# Yarn Berry PnP — key difference
# PnP: No node_modules! Uses .pnp.cjs for module resolution
# Benefit: 70% faster cold installs, zero phantom deps
# Problem: ~15% of packages are PnP-incompatible (check compatibility)
# Check if a package works with PnP:
yarn dlx @yarnpkg/doctor
# Common PnP issues:
# 1. require('some-package') in scripts (use 'import' instead)
# 2. Packages using __dirname in non-standard ways
# 3. Some native addons
# If PnP breaks too many things:
# nodeLinker: node-modules # Fall back to traditional
Yarn Berry's Plug'n'Play mode eliminates node_modules entirely. Instead of a file hierarchy, Yarn generates a .pnp.cjs file that maps package names to their locations in a centralized cache. Module resolution calls are intercepted and answered by this map.
The appeal: zero-install workflows become possible. You can commit the .yarn/cache directory to Git, and teammates can skip yarn install entirely — all packages are already available. For large teams, this means PR branches can be checked out and run without waiting for package installation. The .yarn/cache adds megabytes to git history, but Yarn's caching is efficient enough that this is acceptable for many teams.
The compatibility issue is real. PnP compatibility has improved significantly — most popular packages now work. But the 15% incompatibility rate means some research is required before committing to PnP mode. nodeLinker: node-modules provides an escape hatch that gets you Yarn Berry's workspace features without PnP.
Yarn Berry workspaces have excellent support for workspace: protocol (predating pnpm's adoption of the same pattern) and yarn workspaces foreach for running commands across all packages.
Bun (Speed Demon)
# Bun — all-in-one: runtime + bundler + package manager
curl -fsSL https://bun.sh/install | bash
# bun install — 3-5x faster than npm
bun install
bun add react react-dom
bun remove lodash
# Bun uses npm registry — fully compatible
# bun.lockb — binary lockfile (fast to read, not human-readable)
# Run scripts with bun runtime
bun run start # Much faster than: node server.js
bun run dev # ts files work natively, no transpile step
bun test # Built-in test runner (Jest-compatible)
Bun as a package manager is fast — 3-5x faster than npm for cold installs — but using it means adopting Bun as your JavaScript runtime as well. For pure package management on a Node.js project, Bun works but requires careful testing; the bun.lockb binary lockfile isn't human-readable, and some Bun-specific behaviors differ from Node.js.
The compelling case for Bun is eliminating separate tooling: one binary handles package installation, TypeScript execution, bundling, and testing. Teams adopting Bun for its runtime get the package manager for free. Teams using Node.js should evaluate pnpm instead.
Installation Speed Benchmark
| Package Manager | Cold Install | Warm Install | Disk Space |
|---|---|---|---|
| Bun | ~8s | ~1s | Medium |
| pnpm | ~22s | ~5s | Minimal (shared store) |
| Yarn Berry (PnP) | ~15s | ~3s | Minimal |
| Yarn Berry (nm) | ~28s | ~8s | Medium |
| npm | ~45s | ~15s | Large |
Benchmarks for create-react-app style project (~200 deps). Your numbers will vary.
Lockfile Strategy for Teams
Lockfiles are non-negotiable for reproducible builds — always commit them. But which lockfile you commit signals which package manager your project uses:
package-lock.json→ npmpnpm-lock.yaml→ pnpmyarn.lock→ Yarn Classic or Yarn Berrybun.lockb→ Bun
Teams sometimes get into a state where multiple lockfiles coexist — a developer using pnpm accidentally ran npm install and committed both files. The fix is to add the unused lockfiles to .gitignore and document your package manager in the README. Some teams enforce the correct package manager via the engines and packageManager fields in package.json:
{
"packageManager": "pnpm@9.0.0",
"engines": {
"node": ">=20.0.0"
}
}
Node.js 16.9+ respects the packageManager field via corepack, the built-in package manager version manager.
CI Considerations
For CI performance, pnpm is the clear winner with caching. The ~/.pnpm-store directory can be cached between runs:
# GitHub Actions — pnpm cache
- uses: pnpm/action-setup@v4
with:
version: 9
- uses: actions/cache@v4
with:
path: ~/.local/share/pnpm/store
key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
With a warm cache, pnpm installs take under 30 seconds for most projects. npm with npm ci is predictable but slower.
When to Choose
| Scenario | Pick |
|---|---|
| New project, no specific needs | pnpm |
| Monorepo with many packages | pnpm (workspace: protocol) |
| CI/CD speed is critical | pnpm or Bun |
| Disk space is limited | pnpm (shared store) |
| Zero-compromise compatibility | npm |
| Bun-native project | Bun |
| Already using Yarn, migrating | Yarn Berry (with node-modules linker) |
| Zero node_modules (advanced) | Yarn Berry PnP |
| Corporate environment, no choices | npm |
Security and Dependency Auditing
Package security is a significant concern in 2026, with supply chain attacks on npm packages becoming more frequent. Each package manager handles security auditing differently.
npm audit
npm audit checks your dependency tree against npm's security advisory database and produces a report of known vulnerabilities:
npm audit # Report vulnerabilities
npm audit fix # Auto-fix patches where possible
npm audit fix --force # Force upgrade (may break APIs)
npm audit --json | jq '.metadata.vulnerabilities' # CI scripting
The limitation: npm audit reports severity levels without context. A "critical" vulnerability in a development-only package (a testing tool, a scaffolding CLI) has zero production impact. Teams that automate npm audit --audit-level=critical in CI without filtering dev dependencies get false urgency on non-issues.
pnpm audit
pnpm's audit command adds an important capability: filtering by dependency type:
pnpm audit --prod # Production deps only (excludes devDependencies)
pnpm audit --dev # Dev deps only
pnpm audit --audit-level moderate # Fail CI only for moderate+ vulnerabilities
The --prod flag makes pnpm's audit actionable in CI — you're only blocking deployments for vulnerabilities that affect production code. This is the recommended pattern for automated security gates that don't generate excessive noise.
Yarn Berry and Security
Yarn Berry's security model benefits from its zero-install capability. When you commit the .yarn/cache directory, every package hash is verified against the lockfile on checkout. Modified packages produce checksum mismatches that fail yarn install, catching tampered dependencies. npm's package-lock.json integrity field provides similar guarantees, but Yarn's file-level verification is more comprehensive.
Dependency Update Strategies
Automated dependency updates via Dependabot or Renovate work with all package managers:
# .github/dependabot.yml — pnpm configuration
version: 2
updates:
- package-ecosystem: npm # Dependabot uses 'npm' for all npm-compatible managers
directory: /
schedule:
interval: weekly
groups:
dev-dependencies:
patterns: ['*']
dependency-type: development
Renovate's rangeStrategy: pin option pins all dependencies to exact versions in the lockfile, producing deterministic installs at the cost of more frequent PRs. Teams with automated testing that catches regressions benefit from frequent small updates rather than infrequent large batches.
Phantom Dependency Security Implications
pnpm's strict resolution model has a security benefit beyond disk efficiency: phantom dependencies (packages accessible in node_modules but not listed in your package.json) can be attack vectors. If an attacker compromises a transitive dependency that your code accidentally imports as a phantom, you're affected even though you never explicitly declared a dependency on it.
pnpm's non-flat node_modules prevents phantom dependency usage — your code can only import packages listed in your package.json. For monorepo setups where multiple packages share a single dependency tree, this protection is especially valuable: it prevents one package from accidentally using a dependency that only another package in the monorepo declared, avoiding hidden coupling that breaks when packages are published independently.
Security in the Package Manager Ecosystem
Supply chain security has become a primary concern for JavaScript development. Package managers are the gateway to every dependency in your project — understanding their security models helps you make informed choices.
npm audit and Dependency Scanning
npm audit queries the GitHub Advisory Database for known vulnerabilities in your dependency tree. pnpm audit and yarn npm audit do the same. The audit mechanism itself isn't a differentiator — all three package managers access the same vulnerability data. The differentiator is how they handle the fix path.
npm audit fix automatically upgrades vulnerable packages to the minimum patching version. npm audit fix --force upgrades to potentially breaking versions. The --force flag deserves caution — in large dependency trees, forced upgrades can break indirect dependencies in non-obvious ways. Treat audit fixes as requiring the same care as any dependency upgrade: test thoroughly, especially in CI.
pnpm's audit output includes the dependency path that introduces each vulnerability — the chain from your direct dependency to the vulnerable transitive dependency. This is valuable when evaluating risk: a vulnerability in a build-time utility that never runs in production has different severity than the same vulnerability in a runtime dependency.
Lock File Integrity and Verification
Lock files (package-lock.json, pnpm-lock.yaml, yarn.lock) pin the exact versions of every dependency in your tree. Without a lock file, two developers running npm install at different times might get different transitive dependency versions — a known vector for supply chain attacks where a malicious package version is briefly published between your installs.
All three package managers support lock file verification: npm ci (versus npm install) installs exactly what's in the lock file without updating it. pnpm install --frozen-lockfile does the same. CI pipelines should always use the frozen variant to guarantee reproducibility.
For higher assurance, pnpm's --strict-peer-dependencies flag and lockfile integrity checks (pnpm install verifies content hashes against pnpm-lock.yaml) provide defense against tampered packages. If a package's content doesn't match the hash in the lock file, pnpm refuses to install.
Provenance and Software Bills of Materials
npm now supports package provenance — linking published packages to the exact GitHub Actions workflow that built them. A package with verified provenance provides evidence that the published artifact matches the source code in the repository, reducing the risk of a compromised maintainer account publishing malicious code.
When evaluating packages on PkgPulse, provenance metadata and the publish frequency relative to commit history are indicators of supply chain hygiene. Packages that publish irregularly from undocumented workflows deserve more scrutiny than packages with consistent, CI-automated publishing.
Workspace Security Isolation
In monorepos, a compromised package in one workspace theoretically has access to the shared node_modules directory (in hoisted configurations) and can read packages installed for other workspaces. pnpm's isolated node_modules mode (via nodeLinker: isolated) prevents this by giving each workspace a fully isolated dependency tree using symlinks. This adds some disk overhead but improves isolation between workspace packages.
For teams building applications that handle sensitive data — API keys, user credentials, payment information — isolated workspace dependencies reduce the blast radius of a supply chain compromise in one package from affecting adjacent workspaces.
Compare package manager stats on PkgPulse. Related: Best Monorepo Tools 2026 and Best JavaScript Runtimes 2026.
See the live comparison
View npm vs. pnpm on PkgPulse →