save-prefix is not prepended for major version 0

triaged
cli

(Michael K) #1

I asked the following question on StackExchange and at least one commenter (besides me) think, that it might be a bug.

When I install a package using npm install --save @my-registry/@my-package the caret configured in save-prefix (documented here: https://docs.npmjs.com/misc/config#save-prefix) is not prepended in case the package version of the target package has a major version of 0. I am not sure, whether this is a bug or a feature. In case it is a feature, the documentation linked above should document that and also mention the reason for this deviation. However, I would prefer, that the save-prefix is always prepended.


(Kat Marchán) #2

This is intentional because semver ranges under 1.0.0 can act pretty strange – so it’s by design.


(Lars Willighagen) #3

I can only reproduce it for 0.0.x by the way, in which case range prefixes are pretty much meaningless anyway.


(Kat Marchán) #4

I misspoke, I meant 0.1.0 :sweat_smile:

This is the relevant bit:

  if (isRegistry(requested)) {
    var version = child.package.version
    var rangeDescriptor = ''
    if (semver.valid(version, true) &&
        semver.gte(version, '0.1.0', true) &&
        !npm.config.get('save-exact')) {
      rangeDescriptor = npm.config.get('save-prefix')
    }
    return rangeDescriptor + version
}

(Michael K) #5

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.