What a monorepo needs (the real requirements)

A good monorepo package manager should handle:

1. Workspaces (multiple packages/apps)
2. Fast installs for big repos
3. Deterministic lockfile (same deps everywhere)
4. Good CI caching
5. Minimal “dependency weirdness” (phantom deps, hoisting surprises)
6. Good developer workflow (run scripts across packages, filtering, etc.)

pnpm in monorepos (why it’s usually best)

1) Speed (especially after first install)

• pnpm keeps a global content-addressable store (one copy of each package version).
• Each project uses hardlinks into node_modules. Result: repeated installs are very fast, and huge monorepos benefit a lot.

2) Disk usage (big win)

• With npm, each workspace can duplicate the same packages across subprojects.
• With pnpm, packages are reused from the store. Result: smaller repo footprint and faster docker/CI layers.

3) Strict dependency isolation (less “hidden bugs”)

pnpm is strict:
If package-a doesn’t declare lodash in its package.json, it can’t import it just because some other package installed it.

This prevents the classic monorepo bug:

“It worked on my machine because it was hoisted… but CI broke later.”

4) Workspace tooling feels made for monorepos

pnpm has very ergonomic workspace commands:

• run scripts across all packages
• filter to run on only affected packages
• recursive installs/builds are clean

5) CI caching is usually better

Because pnpm’s store is reusable, caching is simpler and more effective.

In many CI pipelines, pnpm installs become consistently faster after the first cached run.

Best for:
New monorepos, medium/large repos, teams that care about correctness and speed, TurboRepo/Nx repos.

npm in monorepos (when it’s still a good choice)

1) Maximum compatibility / minimum friction

• npm ships with Node by default.
• Some older tools and scripts assume npm-style hoisting behavior. That makes npm “boring and safe” in some enterprise setups.

2) Simpler mental model for some teams

If the team already knows npm and the repo is small-ish, npm workspaces can be “good enough.”

3) Fewer edge cases with legacy tooling

pnpm’s strictness can expose issues in older packages that assumed hoisting.
That’s not pnpm’s fault—it’s correctness—but it can create migration work.

Best for:
Legacy repos, very strict “no new tooling” policy, or ecosystems with fragile dependencies.

Key Differences (quick but important)

Dependency layout

• npm: often hoisted dependencies (deps can appear available even if not declared)
• pnpm: uses a symlinked structure that enforces correctness

Bug prevention

• pnpm catches missing dependencies earlier
• npm may hide missing dependency problems until later

Performance

• pnpm usually wins for bigger repos and repeated installs

Recommendation (simple decision guide)

Pick pnpm if you want:
fast installs
lower disk usage
fewer “phantom dependency” bugs
best monorepo ergonomics

Pick npm if you want:
maximum compatibility
simplest onboarding (no extra tool install)
legacy tooling expectations

My default in 2026: pnpm for almost every new monorepo.

Best-practice setup (works great)

If you choose pnpm, do this:

• Keep one lockfile at repo root
• Use pnpm workspaces
• Add a pinned version for consistency across the team

Example idea (conceptual):

• root package.json with "packageManager": "pnpm@X.Y.Z"

• pnpm-workspace.yaml listing packages like:

  • apps/*
  • packages/*