can act pretty strange
is not a good reason to silently ignore the save-prefix. Especially I do not understand, why they “act strange”.
So I took a look at the SemVer specification and it clearly states, that “0.0.x” is a valid SemVer as well:
A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version.
(Hint: “leading zeroes” refers to the single numbers X, Y and Z)
If you ask me, npm acts strange in this, as the rules for installing ‘^0.0.42’ are pretty clear and are not an exception.
So still: if npm decided to treat 0.0.x specially, it should be documented in the link above - before more people waste their time on finding this out.
As a workaround I will increase the minor versions of all my packages.
By the way: npm init initializes the version field in package.json to 1.0.0, which is a pretty strange version for a newly created package, as I would not want to immediately release my first major version (see https://semver.org/ Rule 4). So on your opinion a plain new module should start with version 0.1.0, right?
Of course, a patch of a not even released package makes no sense. But a minor release of a not released package does not make too much sense as well. Thats why rule 4 states:
Major version zero (0.y.z) is for initial development.
I’d be happy if npm could reconsider their perch.