Package Managers Done Right: npm, pnpm, Yarn and Bun

Package managers are interchangeable until they are not. The differences that matter are how they lay out node_modules, how fast a clean CI install is, and how strictly they stop you using a dependency you never declared.

The layout difference that causes real bugs

npm and Yarn's default mode hoist transitive dependencies to the top of node_modules. That means you can import lodash without ever declaring it, because something else depends on it — and your build breaks the day that other package drops it. pnpm uses a content-addressable store with symlinks so only declared dependencies are reachable, which turns those phantom imports into an immediate error. Adopting pnpm on an existing project usually surfaces two or three undeclared dependencies on the first install; that is the tool working.

Disk and speed, in practical terms

pnpm hard-links from a global store, so ten projects sharing the same version of a large dependency store it once. On a machine with many repositories that is measured in gigabytes saved. Bun's installer is the fastest of the four by a wide margin on a cold install, and npm has closed much of the gap it once had. For most teams the deciding factor is not raw install speed but CI cache behaviour — a warm cache makes all four acceptable, and a misconfigured cache makes all four slow.

Lockfiles: the rules that prevent broken builds

• Commit the lockfile. Always, including for libraries — it makes CI reproducible even though consumers ignore it.
• In CI, use the frozen install: npm ci, pnpm install --frozen-lockfile, yarn install --immutable, bun install --frozen-lockfile. These fail if the lockfile and manifest disagree, which is exactly what you want.
• Never commit two lockfiles. A repo with both package-lock.json and pnpm-lock.yaml installs different trees depending on who ran what.
• Resolve lockfile merge conflicts by taking one side and re-running the install, never by hand-editing.
• Pin the package manager itself with the packageManager field in package.json so Corepack gives everyone the same version.

Version ranges and what they cost

The caret (^1.2.3) allows any 1.x, which is fine because the lockfile pins the actual version. The risk is not the range, it is running an unpinned install in CI — which is precisely what the frozen-install flags prevent. For anything you cannot afford to have change, pin exactly and schedule a dependency update job instead of relying on ranges. Automated update pull requests, batched weekly and run through your full test suite, keep the upgrade cost small and continuous rather than large and occasional.

Supply chain habits worth the five minutes

Disable lifecycle scripts for untrusted installs — npm ci --ignore-scripts — because a postinstall script runs arbitrary code on your machine and in your CI runner. Run npm audit --omit=dev or pnpm audit in CI but do not fail the build on every advisory; triage by whether the vulnerable path is reachable. Watch for typosquats when adding a package: check the download count, the repository link and the publish date of the latest version. A package published three days ago with 40 downloads and a name one character from a popular library is the entire attack.

A default that works

pnpm for applications and monorepos, with packageManager pinned, --frozen-lockfile in CI, a workspace file if there is more than one package, and Dependabot or Renovate opening batched update pull requests. npm remains the safest choice when the project must work for contributors who will not install anything new, and Bun is worth it when install and test speed is the actual bottleneck and you have verified your dependencies run on it.