npm 11 Adds min-release-age — A Built-In Quarantine for New Packages
npm CLI 11, released in February 2026, ships a new config option called min-release-age. It refuses to resolve any package version published less than a configured number of days ago. The idea is simple: give the community time to detect compromised releases before they land in your node_modules. Previously this was only available via pnpm's minimumReleaseAge — now npm has it natively.
What It Does
The setting creates a quarantine window. When npm resolves dependencies, it skips any version whose publish timestamp falls within the configured window. The value is in days. A version published 3 days ago won't resolve if your minimum is 7.
See the official docs for the full specification.
How to Use It
Per-project (recommended) — add to .npmrc in the project root:
min-release-age=7
User-wide:
npm config set min-release-age 7 --location=user
min-release-age cannot be combined with the --before flag. npm will error out if both are set.
Why 7 Days?
Most supply chain attacks are detected within hours to days. The TanStack incident — malicious versions live on npm for hours before being pulled — is a typical window. A 7-day quarantine is conservative enough to catch nearly all incidents while remaining practical for day-to-day development.
For greenfield installs or when adding a brand-new dependency, you may need to temporarily lower or disable the value. That's fine — the point is to make the unsafe path explicit rather than the default.
Our Recommendation
We've added min-release-age=7 to our recommended .npmrc baseline. You'll find it referenced in:
One config line won't solve supply chain security. But stacked with lock files, npm ci, disabled install scripts, and behavioral scanning, it closes the window that most real-world attacks have exploited. Layers win.