In my JavaScript development journey, I started with plain-vanilla npm and later graduated to Yarn 1.x (our team’s package manager of choice for the past few years). Now we’re choosing to move to pnpm. Along the way, we deliberately side-stepped Yarn 4.x (Berry) because it’s effectively a different product rather than an incremental update to Yarn 1.x, and we opted not to go with Bun because it hasn’t been battle-tested at the same level in enterprise environments.
More than anything else, we need pnpm’s minimumReleaseAge policy: a guardrail that refuses to install package versions that have been published only minutes ago. In an era of supply chain attacks, giving the ecosystem a little time to notice and pull malicious releases can make a meaningful difference.
What is a package manager?
A package manager automates dependency installation and versioning for a project. It tracks what your code depends on, downloads those packages (and their dependencies), and keeps a lockfile so installs can be deterministic. That predictability matters for reproducible builds, CI/CD, and debugging: if everyone installs the same dependency tree, you’re less likely to chase “it works on my machine” bugs.
The current landscape
- npm remains the default and most widely used.
- Yarn split into two worlds: classic Yarn 1.x and the newer Yarn 4.x Berry paradigm.
- pnpm has gained momentum for its speed, disk efficiency, and strictness.
- Bun offers attractive performance numbers and an end-to-end toolchain, but we need more enterprise-grade confidence and runway before adopting it.
What makes pnpm different?
Pnpm’s main superpower is how it stores dependencies. Instead of copying the same package version into every project, pnpm keeps a single copy in a global store and uses hard links/symlinks to connect each project’s node_modules to it. In practice, that means faster installs on warm caches and dramatically less disk usage across many projects.
There’s also a subtle but important security and correctness angle: pnpm’s strict node_modules layout makes it harder to accidentally rely on transitive dependencies you didn’t declare. That’s a nice habit to build, especially as dependency trees grow.
minimumReleaseAge: why it matters
pnpm’s minimumReleaseAge setting lets you delay installing a newly published package version for a configurable number of minutes. The goal is simple: many malicious releases are found quickly and removed from the registry; waiting even a day can block a surprising number of supply chain attacks from ever reaching your repo.
We can even be selective with exceptions (for example, allowing a critical hotfix while keeping everything else delayed or allow private, homegrown packages to ), which makes it practical in real-world workflows.
Our plan
We’re adopting pnpm with minimumReleaseAge as a baseline safety posture, and evaluating additional controls (audit tooling, signed packages, stricter CI checks) as needed. More broadly, this isn’t just a tool upgrade; it’s a cultural shift toward more deliberate dependency hygiene.
If you’re coming from npm or Yarn 1.x, pnpm is worth the trial run. For us, it’s the balance of speed, reliability, and security controls we need right now.