Should You Switch from npm to pnpm?

You’ve probably seen pnpm mentioned in monorepo setups, CI configs, and framework docs. Maybe a colleague swears by it. But is switching actually worth the friction for your day-to-day frontend work, or is it solving problems you don’t have yet?

Here’s what you actually need to know.

What Makes pnpm Different from npm

pnpm isn’t just a faster npm. The real differences are structural.

npm creates a flat node_modules directory, which means your code can accidentally import packages you never declared as dependencies — a problem called phantom dependencies. pnpm uses a content-addressable store with hard links and symlinks, so only your declared dependencies are accessible at the root level. This makes dependency resolution stricter and more reproducible.

The other major difference is disk usage. pnpm stores each package version once globally and hard-links it into your projects. If you maintain multiple Next.js or Vite projects locally, you’re not duplicating hundreds of megabytes per project.

For a deeper breakdown of the storage model and dependency isolation, the official pnpm vs npm comparison is worth skimming.

pnpm 11 and the Security-First Shift

pnpm 11, released in April 2026, continues a trend that’s been building across recent major versions: prioritizing security and determinism over raw speed.

The most important behavior to know before switching: pnpm now blocks dependency lifecycle scripts by default unless explicitly approved. This is the pnpm approve-builds workflow introduced in pnpm 10. If you install a package with a postinstall script — common with packages that compile native binaries, like sharp, esbuild, or canvas — the install will succeed, but the script won’t run until you approve it.

This surprises developers who expect everything to just work. Run pnpm approve-builds interactively, or configure allowed build dependencies in pnpm-workspace.yaml:

onlyBuiltDependencies:
  - sharp
  - esbuild

It’s a deliberate tradeoff: more friction upfront, fewer supply chain surprises later.

Workspaces and Monorepo Tooling

This is where pnpm pulls noticeably ahead. npm workspaces work, but pnpm’s workspace implementation is more ergonomic for larger setups.

You define packages in a pnpm-workspace.yaml file:

packages:
  - 'apps/*'
  - 'packages/*'

Then you get powerful filtering out of the box:

pnpm --filter @myapp/ui build
pnpm --filter "...^@myapp/ui" test  # run tests in packages that depend on ui

For teams using Turborepo or Nx, pnpm’s workspace protocol (workspace:*) integrates cleanly and keeps internal dependencies explicit.

Pinning Versions with the packageManager Field

One practical step regardless of whether you use Corepack: add a packageManager field to your package.json to signal which package manager and version your project expects.

{
  "packageManager": "pnpm@11.0.0"
}

Corepack can enforce this in environments where it’s enabled, but even without Corepack, it communicates intent clearly to your team and CI setup.

CI Integration with GitHub Actions

- uses: pnpm/action-setup@v6
  with:
    version: 11
- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'pnpm'
- run: pnpm install --frozen-lockfile

Always use --frozen-lockfile in CI. It prevents silent lockfile mutations and makes installs deterministic.

The official pnpm CI documentation also includes examples for GitHub Actions, GitLab CI, CircleCI, Azure Pipelines, and Bitbucket Pipelines.

When the Switch Is Worth It

pnpm makes the most sense if you’re working in a monorepo, managing many local projects, or want stricter dependency isolation by default. The pnpm approve-builds security model is genuinely useful for teams that care about supply chain hygiene.

If you’re maintaining a single-package app and npm is working fine, the migration friction probably isn’t worth it. npm workspaces are mature enough for straightforward setups, and the ecosystem default still has real value.

Conclusion

The honest answer: try pnpm on a new project first. The command surface is nearly identical, the lockfile is readable, and most frontend frameworks — including Next.js, Vite, and Astro — support it without extra configuration. If the strictness and disk savings click for your workflow, scaling it up to existing projects becomes a much smaller decision.

FAQs

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.