Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RRFC] Add semver filter to the outdated command #359

Open
lomby92 opened this issue Apr 1, 2021 · 10 comments
Open

[RRFC] Add semver filter to the outdated command #359

lomby92 opened this issue Apr 1, 2021 · 10 comments

Comments

@lomby92
Copy link

lomby92 commented Apr 1, 2021

Motivation ("The Why")

I was managing a repository and wanted to see if there were any new major releases in the dependencies. I was interested only to major releases changes but the npm outdated command showed to me also minor and patch changes.

Example

Allow to show only some specific type of semver changes, eg: only major and minor.

How

Current Behaviour

The npm outdated command shows all dependencies with an update

Desired Behaviour

Allow to specify a filter parameter like --include-versions that takes as input a string or a list of comma-separated strings.

Example:

npm outdated

Package      Current          Wanted        Latest
dep1         1.0.1            1.0.1         1.1.0
dep2         3.2.122          3.2.122       4.0.0
dep1         0.0.1            0.0.1         0.0.2


npm outdated --include-versions major,minor

Package      Current          Wanted        Latest
dep1         1.0.1            1.0.1         1.1.0
dep2         3.2.122          3.2.122       4.0.0

References

  • n/a
@lomby92 lomby92 changed the title [RRFC] <title> [RRFC] Add semver filter to the outdated command Apr 1, 2021
@ljharb
Copy link
Contributor

ljharb commented Apr 1, 2021

In the last example, the “1” is a major version. In vX.Y.Z, v0.X.Y, and v0.0.X, x is the major, y the minor, and z the patch.

@lomby92
Copy link
Author

lomby92 commented Apr 1, 2021

https://semver.org/

I always used: major.minor.patch

@ljharb
Copy link
Contributor

ljharb commented Apr 1, 2021

See https://semver.org/spec/v1.0.0.html - the npm ecosystem generally uses the rubric I described.

@lomby92
Copy link
Author

lomby92 commented Apr 2, 2021

I have not found what you say, not even in this document. Can you show me where the quote is?

@ljharb
Copy link
Contributor

ljharb commented Apr 2, 2021

https://semver.org/spec/v1.0.0.html#spec-item-6 says there are no non-breaking change before v1. the undocumented convention the npm ecosystem uses, and the way npm itself works with ^ and ~ (ranges it defines, that are not in the specification) work the way I described.

@lomby92
Copy link
Author

lomby92 commented Jun 9, 2022

So? Even if NPM uses an internal convention, the proposal could be good to be added, no?

In that case, if a package moves from 0.0.1 to 0.0.2 it should be interpreted as a major change.
Or, if moving from 0.1.4 to 0.1.5: it's a minor change.

This behaviour should be consistent with the undocumented way NPM works

@ljharb
Copy link
Contributor

ljharb commented Jun 9, 2022

Yes, 0.0.1 to 0.0.2 is a major change; and 0.1.4 to 0.1.5 is a minor change, and npm should and does work this way with the ~ and ^ range operators.

@lomby92
Copy link
Author

lomby92 commented Jun 9, 2022

Ok, the next step is to open a PR with my RFC. Is it right?

@ljharb
Copy link
Contributor

ljharb commented Jun 9, 2022

I think it’s probably best to wait until query has landed, since that’s how it’d be implemented and would affect the api.

@lomby92
Copy link
Author

lomby92 commented Jun 9, 2022

Is that RFC? #564
(if it's, seems to be really interesting)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants