(FR): Implement 'minimumReleaseAge' as a security feature (like pnpm added recently)

[webextensions]

Ref:

• Add a way to enforce a minimum package age policy pnpm/pnpm#9921
• https://pnpm.io/settings#minimumreleaseage
• https://socket.dev/blog/pnpm-10-16-adds-new-setting-for-delayed-dependency-updates
• Feature Request: Cooldown Parameter(s) raineorshine/npm-check-updates#1532

Copying an excerpt from one of these articles:

Following a wave of high-profile supply chain attacks targeting popular npm packages, pnpm has shipped a new minimumReleaseAge setting in version 10.16 that delays installation of newly published packages.

[karlhorky]

There is also this RRFC for npm from 2022:

• [RRFC] Ability to set minimum maturity (in days) of versions to upgrade rfcs#646

Maybe this new issue would be considered as a duplicate of this other issue.

[theodorejb]

There also should be an easy way to ignore postinstall scripts for dependencies that aren't on a specific whitelist (also like Pnpm has). That way I could allow scripts for e.g. esbuild, but not for every other dependency or subdependency which has no need for them.

Edit: there is an existing RFC requesting this from 2021, and an even older discussion going back to 2019.

[limonte]

Maybe this new issue would be considered as a duplicate of this other issue.

This is not a duplicate. The proposed here minimumReleaseAge is not the same as proposed stabilityDays in npm/rfcs#646

I described the difference here: npm/rfcs#646 (comment)

[40detectives]

So, correct me if I'm wrong, but from reading the docs about the --before flag and the discussion at npm/rfcs#646 (especially this comment)

...the main differences compared to the current --before would be:

1. The format of the string passed to the flag: date string in npm's --before VS a number (of minutes) in pnpm's --minimumReleaseAge. (It’s convenient: set it up once and forget about it).
2. The behavior resolving a dist-tag like some-package@latest, as --before seems to resolve to a previous major in some cases.

[twesterhuys]

It’s convenient

I would argue however, the real power comes from devs and more importantly projects being able to set a default policy for everyone working on the project (through npmrc, environment variables and alike).

[shellscape]

I can't believe there are still people using the npm cli in 2025.

[webextensions]

@limonte
As per your comment in npm/rfcs#646 (comment) , do you mean that --before in npm (https://docs.npmjs.com/cli/v11/commands/npm-install#before) can effectively provide the same functionality as pnpm's minimumReleaseAge (seemingly with a slightly different format of providing that duration) ?

[omonk]

@webextensions - this would be very handy if before flag accepted date math but from the docs it doesn't appear to support that.

Given its null or Date then the limitation with the current implementation is that it requires an absolute date vs. relative time from now which minimumReleaseAge includes.

[twesterhuys]

@omonk plus --before or a default for it can not be set in an npmrc/environment variable, right?

[omonk]

@twesterhuys from the docs it's possible forbefore to be placed inside of a .npmrc file but I don't even know if a hacky implementation on a preinstall script could make this really dynamic. Having it native to the npm cli would be much better

[limonte]

@limonte As per your comment in npm/rfcs#646 (comment) , do you mean that --before in npm (https://docs.npmjs.com/cli/v11/commands/npm-install#before) can effectively provide the same functionality as pnpm's minimumReleaseAge (seemingly with a slightly different format of providing that duration) ?

@webextensions I think so yes. It's less handy than minimumReleaseAge because you need to calculate now() - N days manually and pass that to --before as Date, but yes it's basically the same thing.

[PeteLloyd]

minimumReleaseAge also comes with minimumReleaseAgeExclude, which isn't supported via --before. If you're shipping a multi-component system then you need to pull in fresh versions of your trusted internally-maintained components without pulling in fresh exploits from outside.

[43081j]

The difference in naming probably causes confusion here but npm has had before for a while now which can indeed achieve exactly the same thing

This issue should probably be renamed to be clear that the missing functionality is that before should support date math. Not that npm needs a separate flag - npm is the one ahead here