· yarn / npm / package-manager
Yarn vs npm 2026 — does Yarn still matter?
npm is the safe default. Yarn Berry earns its place in one specific scenario: large TypeScript monorepos with zero-install CI. Here is where that line falls.
By Ethan
1,713 words · 9 min read
npm is the safe default in 2026. Yarn Classic is done for new projects — say that plainly and move on. Yarn Berry (v4) still earns its place in one scenario: large TypeScript monorepos where zero-install CI pipelines and workspace constraints justify the setup cost. Outside that window, npm or pnpm is simpler and carries less ecosystem risk.
Who this is for
JavaScript and TypeScript engineers deciding whether to adopt, keep, or migrate away from Yarn in 2026. If you are starting a React Native or Expo project, skip straight to caveats first — PnP is a non-starter there and the rest of this article won’t change that.
What we compared
npm 11.15.0, Yarn Classic 1.22.22, Yarn Berry 4.15.0 — all current stable releases as of 2026-05-26. Benchmark data from pnpm.io/benchmarks, which runs an automated, open fixture daily. Adoption figures from State of Frontend 2024 (n ≈ 6,000+ developers).
Note on the three-way landscape: pnpm has pulled close to Yarn in market share and surpassed it in developer satisfaction. This article stays focused on npm vs Yarn, but pnpm is the real challenger in new projects — if you’re evaluating all options, test pnpm too.
Feature comparison
| Feature | npm 11 | Yarn Classic 1.x | Yarn Berry 4.x |
|---|---|---|---|
| Workspaces | ✅ (since 2020) | ✅ | ✅ + Constraints |
| Parallel workspace commands | Partial | ✅ | ✅ (--parallel, --since) |
| PnP (no node_modules) | ❌ | ❌ | ✅ (default) |
| Zero-installs | ❌ | ❌ | ✅ (opt-in) |
| TypeScript @types auto-management | ❌ | ❌ | ✅ |
| Monorepo constraint rules | ❌ | ❌ | ✅ |
| Hardened lockfile mode | ❌ | ❌ | ✅ |
| Provenance attestation (Sigstore) | ✅ | ❌ | ❌ |
| Plug-in system | ❌ | ❌ | ✅ |
npx / dlx equivalent | ✅ npx | ❌ | ✅ yarn dlx |
| React Native support | ✅ | ✅ | ⚠️ node-modules linker required |
The 2016 gap that made Yarn compelling — deterministic installs, offline cache, workspaces — is closed. npm v7 (2020) addressed all three. What remains is in the bottom half of this table: Yarn Berry’s constraint engine and zero-installs on one side, npm’s Sigstore provenance on the other.
Findings
Install speed
From pnpm.io/benchmarks, “lots of files” fixture, 2026-05-26:
| Scenario | npm 11 | pnpm 10 | Yarn (node-modules) | Yarn PnP |
|---|---|---|---|---|
| Cold install (no cache, no lockfile) | 27.6 s | 7.3 s | 7.1 s | 2.9 s |
| Cached + lockfile + existing node_modules | 1 s | 372 ms | 4.5 s | n/a |
| Dependency update | 6.5 s | 3.1 s | 5.1 s | 2.5 s |
Yarn PnP wins cold-install at 2.9 s because it copies zip archives rather than thousands of individual files. npm at 27.6 s cold is the clear loser — a 9× gap against Yarn PnP.
On a CI pipeline running 50 pull requests per day, npm’s cold install adds roughly 23 minutes of compute time daily. That is a meaningful bill for a step that delivers zero business value.
Zero-installs takes this further. Commit .yarn/cache to your repository, and CI skips yarn install entirely. Typical saving on a large Next.js project: 28–35 seconds per run. The tradeoff is repository size — expect 50–200 MB of compressed cache. On GitHub Actions, that is a one-time checkout overhead rather than a per-run penalty. For runners with fast NVMe and warm actions/cache restoration, pnpm with a cache hit approaches zero-installs performance. Zero-installs is simpler to reason about: no cache miss, no stale state.
PnP compatibility — real friction, specific failure modes
PnP enforces what npm silently permits: you cannot use packages you have not declared as direct dependencies. The behavior is correct. The problem is the ecosystem.
Known breakage points as of 2026-05-26:
- React Native / Expo — officially unsupported with PnP. Requires
nodeLinker: node-modulesin.yarnrc.yml. This is documented on the Yarn PnP page, not a community workaround. - Vite on Windows — crashes when the Yarn cache is on a different drive from the project (vitejs/vite#15496, closed as duplicate; underlying behaviour unresolved).
- Vite + ESM —
package.json type: modulecombined with PnP fails with “module not found” (vitejs/vite#4307). - Vitest @vitest/browser — cannot resolve
vitevia PnP because@vitest/browserdoes not declare it as a direct dependency (vitest-dev/vitest#6101). - Next.js — longstanding PnP edge cases across app router and middleware (vercel/next.js#25296).
The standard workaround for all of these: set nodeLinker: node-modules in .yarnrc.yml. You keep Yarn Berry’s features — zero-installs, constraints, plug-ins — without PnP’s strictness. Many teams do exactly this. It is a legitimate configuration, but it means you are not getting PnP’s install speed benefits. You are using Yarn as an upgraded v1 with a better plugin system.
Plan 1–3 days of compatibility work when adopting PnP on a real project with mixed dependencies. The official migration guide covers the steps but underestimates IDE setup time.
Monorepo DX
This is where Yarn Berry has no peer.
Constraints is a JavaScript/TypeScript rule engine that enforces consistency across package.json files in a monorepo. A typical rule: “every package must use the same TypeScript version.” Another: “no package may declare a peer dependency that isn’t in the root’s devDependencies.” No other package manager ships this. For teams managing 20+ packages, constraints pay for themselves in prevented dependency drift.
Beyond constraints, Yarn Berry added yarn workspaces foreach --parallel in v3, and --since filtering to run commands only for packages changed since a given git ref. These are niche on a two-package monorepo. They matter on a 50-package monorepo where a full rebuild takes minutes.
npm workspaces cover the basics: hoisted installs, --workspace= flag, npm run --workspaces. What they still lack in 2026: no --parallel flag for workspace commands, no constraints engine, no multi-package publish support. If you hit these limits, Yarn Berry is the only in-tree option. Turborepo and Nx both support all three package managers; neither requires Yarn Berry specifically.
Security
npm and Yarn Berry made different bets.
npm went the attestation route. The --provenance flag during publish generates a Sigstore attestation — cryptographic proof of which repository and workflow built the package. Consumers verify it with npm audit signatures (npm 9+). This requires publishing from GitHub Actions or GitLab CI; other CI providers are not yet supported. It is npm’s biggest security differentiator in 2026.
Yarn Berry went the lockfile-integrity route. Hardened Mode, introduced in v4.0, automatically enables on public GitHub PR CI. It validates package metadata on every install and checks resolution coherence — guarding against lockfile poisoning, where a malicious pull request edits yarn.lock to swap a dependency for a compromised version. The Shai-Hulud supply chain attacks of September–November 2025 underscored that lockfile integrity is now table stakes. Neither approach stops credential theft entirely, but both reduce the attack surface.
These are not competing: attestation protects what you publish, hardened mode protects what you install. If you publish packages to npm, provenance matters. If you accept external PRs, lockfile hardening matters.
Adoption
State of Frontend 2024:
| Tool | Share |
|---|---|
| npm | 56.6% |
| Yarn (all versions) | 21.5% |
| pnpm | 19.9% |
npm’s share is inflated by passive installs — it ships with Node.js. Yarn Classic’s 21.5% reflects inertia on existing projects, not new adoption; Yarn Classic has been in maintenance mode since 2020 with no new features and security fixes only.
The real trend is pnpm. It is at 19.9% and rising. Developer satisfaction data from State of JS 2023–2024 shows pnpm overtaking Yarn for the second consecutive year. Teams that tried Yarn Berry, hit PnP friction, and left largely moved to pnpm, not back to npm. pnpm’s content-addressable store and hard-link approach delivers most of Yarn PnP’s speed advantages without the compatibility overhead.
Verdict
Use npm when:
- You maintain open-source tooling or a library and want universal compatibility. Your README should not need a package manager note.
- Your stack includes React Native, Expo, or heavy ESM customisation where PnP compatibility is unvalidated.
- Your team is small and infrastructure cost should be minimal. npm ships with Node.js; no extra configuration layer, no Corepack pin.
Use Yarn Berry (v4) when:
- You run a TypeScript monorepo with 20+ packages and need Constraints to enforce consistency across
package.jsonfiles. This is Yarn Berry’s clearest moat. - CI install time is a hard budget constraint. Zero-installs eliminates the install step entirely — worth 30–120 seconds per run on large dependency trees at scale.
- Your team has validated PnP compatibility upfront and accepts the ongoing maintenance of
.yarnrc.ymland compatibility shims.
Do not start new projects on Yarn Classic (v1):
Frozen since 2020. No new features, security fixes only. If you’re on it today, migrate. The npm path is low-complexity: delete yarn.lock, run npm install, swap yarn install → npm ci in CI. Budget 1–2 hours for a typical project. The Yarn Berry path takes 1–3 days on a real project and is only worth it if you specifically need monorepo constraints or zero-install CI.
Caveats
The benchmarks here come from pnpm.io/benchmarks. pnpm maintains the suite, and the fixture is designed around pnpm’s architecture. The relative ordering — Yarn PnP fastest cold, npm slowest — is consistent with independent measurements, but treat the absolute numbers as directional rather than definitive for your specific project.
This article does not go deep on pnpm. If you’re evaluating a package manager switch, test all three. pnpm is the better upgrade path from npm for most teams that don’t need Yarn’s specific monorepo features.
References
| Source | URL |
|---|---|
| pnpm benchmark suite | pnpm.io/benchmarks |
| Yarn 4.0 release blog | yarnpkg.com/blog/release/4.0 |
| Yarn PnP docs | yarnpkg.com/features/pnp |
| Yarn migration guide | yarnpkg.com/getting-started/migration |
| npm provenance (GitHub Blog) | github.blog/security/supply-chain-security/introducing-npm-package-provenance/ |
| vitejs/vite#15496 | github.com/vitejs/vite/issues/15496 |
| vitejs/vite#4307 | github.com/vitejs/vite/issues/4307 |
| vitest-dev/vitest#6101 | github.com/vitest-dev/vitest/issues/6101 |
| vercel/next.js#25296 | github.com/vercel/next.js/discussions/25296 |
| State of Frontend 2024 | tsh.io/state-of-frontend |
| State of JS 2023–2024 | 2024.stateofjs.com/en-US |