BuildNot yet confirmed elsewhere1 publisher2 min readPublished
A one-day install cooldown is 1440 in pnpm, 1 in npm and 86400 in Bun
pnpm, npm, Bun and Yarn can each refuse versions younger than a set age, using minutes, days, seconds and minutes respectively. Pasting pnpm's 1440 into npm makes the cooldown 1440 days, roughly 3.9 years.
The Engineer · Build desk
1440 pasted into npm's min-release-age, which counts days, gives a 1440-day cooldown, roughly 3.9 years. 1440 pasted into Bun, which counts seconds, gives 24 minutes. Bun's 86400 pasted into pnpm, which counts minutes, gives 60 days.
| Figure | Value | Note | Claim |
|---|---|---|---|
| 1440 pasted into npm's min-release-age | 1,440 days | roughly 3.9 years | 18 |
| 1440 pasted into Bun | 24 minutes | 19 | |
| 86400 pasted into pnpm | 60 days | 20 |
What happened
- The guide says a malicious npm version is usually spotted and pulled within hours, and that the damage is done in that gap by machines that installed it first.
- Since pnpm 11 the gate is on by default at 1440 minutes, set through minimumReleaseAge in pnpm-workspace.yaml.
- npm added min-release-age in CLI 11.10, measured in days, and ships it off by default.
- pnpm's built-in 1440 default falls back to a too-new version, but setting minimumReleaseAge yourself flips minimumReleaseAgeStrict to true and installs then fail.
- Both pnpm and Bun treat an undated version as passing, and some private registries and mirrors do not serve the time metadata the gate reads.
Why it matters
- cost Teams pay for the gate in red CI on bot pull requests: the new version is younger than the cooldown, the frozen install fails, and the fix is to delay Dependabot or Renovate or maintain exclusions.
- decision Each exclusion is a choice between a version-pinned entry and a package name, and only the pinned form keeps future releases of that package behind the gate.
- contradiction npm config ls --long can report min-release-age as null while npm install honors it, so the reliable check on npm is an install, not a read of the config.
- constraint A cooldown holds back a CVE fix as well as a poisoned release, so a team that adopts one needs a path for urgent patches.
The whole defence is a timing condition: the poisoned version has to be pulled before the setting expires. A 1440-minute default is 24 hours [17]. That covers the \"within hours\" case the dev.to guide describes [2] and nothing slower.
Units are where a copied snippet goes wrong. One day is 1440 in pnpm and Yarn, 1 in npm and 86400 in Bun [4][5][6][7]. Two of the four tools agree on minutes, which is as close as the field gets to a standard.
Paste pnpm's 1440 into npm and the cooldown is 1440 days, roughly 3.9 years [18]. Paste it into Bun and it is 1440 seconds, or 24 minutes [19]. The guide puts the Bun mistake at 24 seconds [8]. Going the other way, Bun's 86400 pasted into pnpm is 60 days [20]. The guide's advice is to leave a comment with the unit next to the number every time [8].
Coverage reaches the whole tree. According to the guide, pnpm's docs say the gate applies to transitive dependencies, so a package that publishes constantly, such as caniuse-lite, can trip it [9].
Lockfiles are handled differently. Bun applies the gate only during new resolution and leaves entries already in bun.lock alone [11]. pnpm re-checks every lockfile entry on install by default, which catches a lockfile generated under a weaker setting [11]. Setting trustLockfile: true turns that re-check off [11].
In our view a team shipping to production should keep the strict behavior pnpm switches on once you set the value yourself. A failed install is visible. The built-in default quietly falls back to the too-new version [10]. The context for that call is a team with CI and someone who can add an exclusion when a build goes red.
The guide text available to us ends before its advice on overriding the gate for urgent patches.
What to watch
- Whether the open npm CLI issue on npm config ls --long reporting null gets fixed, so config reads can be trusted.
- Whether npm turns min-release-age on by default, as pnpm did in version 11.
- Whether private registries and mirrors start serving time metadata, or pnpm users set minimumReleaseAgeIgnoreMissingTime to false.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence50
- Adoption40
- Hype gap+10
- Incentives
- Insufficient
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Most npm supply-chain attacks follow one script: phish a maintainer or steal a publish token, push a poisoned patch release, and wait for every caret range to pick it up on the next install.
- [2]
The malicious version usually gets spotted and pulled within hours, and the damage is done in those hours by machines that installed it before anyone noticed.
- [3]
A dependency cooldown makes the package manager accept only versions that have existed for a while, so the rest of the ecosystem acts as the canary.
- [4]
pnpm configures the gate as minimumReleaseAge in pnpm-workspace.yaml, in minutes; since pnpm 11 it is on by default at 1440 minutes.
- [5]
npm added min-release-age in CLI 11.10, measured in days and off by default; the example is min-release-age=1 in .npmrc.
- [6]
Bun uses seconds, set as minimumReleaseAge under the [install] table in bunfig.toml; the example value for one day is 86400.
- [7]
Yarn Berry 4.10 and later calls the setting npmMinimalAgeGate, measured in minutes; the example value is 1440 in .yarnrc.yml.
- [8]
The guide says that when switching package managers or copying a snippet written for another tool, it is easy to set a 1440-day cooldown in npm or a 24-second one in Bun, and advises leaving a comment with the unit next to the number every time.
- [9]
The gate applies to transitive dependencies; pnpm's docs are explicit that it covers the whole tree, so a frequently published deep dependency such as caniuse-lite can trip it.
- [10]
pnpm's built-in default of 1440 is non-strict for backward compatibility and quietly falls back to the too-new version; once you set minimumReleaseAge yourself, minimumReleaseAgeStrict flips to true and the install fails instead.
- [11]
Bun applies the gate only during new resolution and leaves entries already in bun.lock alone; pnpm by default re-checks every lockfile entry against the policy on install, which catches a lockfile generated under a weaker setting, and trustLockfile: true turns that off.
- [12]
The gate relies on the registry's time metadata; some private registries and mirrors do not serve it, and both pnpm and Bun treat an undated version as passing. pnpm can tighten this with minimumReleaseAgeIgnoreMissingTime: false.
- [13]
An open npm CLI issue reports that npm config ls --long shows min-release-age = null even though npm install honors the setting, because npm converts it to a --before date internally; the guide says to test with an install.
ReportedSupportedSource: dev.to guide on dependency cooldowns, citing an open npm CLI issueView cited source - [14]
The most common complaint after pnpm 11 shipped was Dependabot: the bot opens a PR when a new version appears, CI runs a frozen install, the version is younger than the cooldown, and CI goes red. Options are to delay the bot (Dependabot and Renovate both support a minimum age or cooldown) or add a narrow version-pinned exclusion.
- [15]
Pinning an exclusion to a specific version beats excluding a whole package name, because a name-level exclusion lets every future release of that package skip the gate; pnpm can remove stale exclusions with minimumReleaseAgeExcludePrune: true.
- [16]
Urgent security patches are the other real cost: when a CVE fix lands and you need it now, the cooldown is in your way.
- [17]
The pnpm default of 1440 minutes equals 24 hours.
- [18]
The value 1440 pasted into npm's min-release-age, which is in days, is a 1440-day cooldown, roughly 3.9 years.
- [19]
The value 1440 pasted into Bun's minimumReleaseAge, which is in seconds, is a cooldown of 24 minutes.
- [20]
Bun's one-day value of 86400 pasted into pnpm, which counts minutes, is a cooldown of 60 days.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toDependency Cooldowns: Make Your Package Manager Wait Before It Trusts New Code
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Dependency cooldownsFollow
- Software Supply Chain SecurityFollow
- JavaScript package managementFollow
Entities
- pnpmFollow
- npm registryFollow
- BunFollow
- Yarn BerryFollow
- DependabotFollow
- RenovateFollow