npm-update does NOT follow SemVer

[fulldecent]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

The documentation states:

If the dependence were on ^0.4.0... Then npm update will install dep1@0.4.1, because that is the highest-sorting version that satisfies ^0.4.0 (>= 0.4.0 <0.5.0)

which is exactly how it behaves.

Also, the documentation states:

This command will update all the packages listed to the latest version (specified by the tag config), respecting the semver constraints of both your package and its dependencies (if they also require the same package).

Expected Behavior

These two above statements in documentation are logically incompatible. SemVer does NOT consider 0.4.1 as an upgrade from 0.4.0.

SemVer is defined at: https://semver.org. And it states specifically:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

https://semver.org/#spec-item-4

Steps To Reproduce

Recommendation:

Update the program behavior to actually support SemVer for the carat (^) operator.

-or-

Update documentation to clarify that this is NOT SemVer. And then actually implement a SemVer with some other operator.

Environment

• OS: macOS 11.4
• Node: 14
• npm: 7

[ljharb]

You're looking at the latest version of semver. The original semver spec indeed worked the way npm works.

v0.4.1 is a nonbreaking update from v0.4.0. It's semver. and it's how npm works.

[fulldecent]

The version 1.0.0 SemVer (and 1.0.0 beta) also says the same thing:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

https://semver.org/spec/v1.0.0.html#spec-item-6

I don't disagree that maybe some pre-recorded-history (i.e. on https://semver.org) draft of SemVer may have said something different. But if that is the case, it might be helpful if documentation is updated to reference this prior version of the specification.

[ljharb]

Fair enough.

[ruyadorno]

I believe there's a historic context on that divergence, ref: semver/semver#221

Maybe a more technically correct way to phrase it in the docs would be to refer to it as "node-semver" (the actual implementation) instead.

[ljharb]

That would be great, and would simplify a lot of related discussions in the wider community :-)

[fulldecent]

That would be a welcome change.

Of course now we have the bug that The npm-semver package advertises that it is an implementation of SemVer which it is not.

The long term solution here is to call this "NPM-flavored SemVer", document somewhere exactly what those words mean, and then everywhere NPM is using this thing use the fully qualified reference.

^^ this would be consistent with how GitHub uses GitHub-flavored Markdown and everywhere GitHub is telling you about Markdown it is fully qualifying it as GFM along with the link to that documentation.