[Feature-request/discussion] Ability to set minimum maturity (in days) of versions to upgrade

[limonte]

New feature motivation

Late Saturday evening I was thinking about lovely ... npm dependencies and their security in particular. And my thoughts seem to be either unusual or simply foolish because I couldn't find anything related.

When a vulnerability is introduced to an npm package, it takes at least several days to discover the vulnerability and to report the vulnerable release to security databases (npm, Snyk, dependabot, etc.)

Because of that reason, it would make sense for developers to use 3rd party dependencies with version that matches these conditions:

1. as latest as possible (the obvious one)
2. free from vulnerabilities, i.e. not present in npm/Snyk/dependabot security databases
3. X days mature, because of the reason mentioned above - it takes time to discover and report vulnerabilities

New feature description

It would be nice to be able to set the minimal maturity for the version to upgrade, for example, if for the some-cool-package two new versions are available, one was released 10 days ago and another one was released 1 hour ago, it'd be safer to upgrade to the older one because the one that was just released has bigger chance to be vulnerable.

New feature implementation

The parameter which would set the minimum maturity required for versions, possibly in days. But the implementation is something to discuss further if what I'm proposing does make sense to you.

Thank you!

[ljharb]

Time passing doesn’t make packages more mature, and if this kind of delay is made easy, it’ll be encouraged as if it’s a best practice - and then, the amount of time it takes for the community to discover these things will increase, defeating the entire point.

This was already discussed here: npm/rfcs#549

[limonte]

Time passing doesn’t make packages more mature, and if this kind of delay is made easy, it’ll be encouraged as if it’s a best practice - and then, the amount of time it takes for the community to discover these things will increase, defeating the entire point.

This was already discussed here: npm/rfcs#549

I disagree. As a maintainer of a popular plugin I several times shipped a bug or a breaking change in a patch release. Usually these issues are noticed by users during next several hours and after several more hours I ship another patch release with a fix.

From the npm ecosystem POV it would not be good if the majority of users would use only mature packages because as you said that would defeat the entire point.

But developers who care about stability and safety would IMO benefit from the suggested feature.

Read more here: https://docs.renovatebot.com/configuration-options/#stabilitydays

[ljharb]

The reason they are noticed, though, is because your users aren’t waiting to upgrade.

[ljharb]

Users who care about stability should be using a lockfile, and when upgrading, can set the --before option to as many days ago as they like.

[limonte]

Users who care about stability should be using a lockfile, and when upgrading, can set the --before option to as many days ago as they like.

Thanks for the suggestion @ljharb! I didn't know about --before. Is --before option undocumented? I can't find it in npm upgrade --help.

Also, it's not exactly what I'm looking for. Let me demonstrate with a simple example:

• some-cool-package has 6.6.6 with a bug released 4 days ago and 6.6.7 with bug-fix released 2 days ago
• with --before="3 days" the buggy version would be installed which would be the exact opposite of desired
• with --stability="3 days" neither 6.6.6 nor 6.6.7 would be installed which is desired

[fritzy]

Can you create an RRFC in that repo?