search

npm / cli

the package manager for JavaScript
https://docs.npmjs.com/cli/
Other
8.5k stars 3.18k forks source link

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

Closed limonte closed 2 years ago

limonte commented 2 years ago

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 commented 2 years ago

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: https://github.com/npm/rfcs/issues/549

limonte commented 2 years ago

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 commented 2 years ago

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

ljharb commented 2 years ago

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 commented 2 years ago

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:

fritzy commented 2 years ago

Can you create an RRFC in that repo?