npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

`npm install somePackage@latest` should be able to be told to only install GA releases

Hi all,

NB: this request is somewhat related to my other feature request at should display latest GA version if current version is a prerelease

As a consumer of npm packages, I only want to install GA releases, that is, non-prereleases, via npm install, so that I do not accidentally depend on prerelease versions of packages. If an explicit version is given (after the @ sign following the package name), npm install would behave as it currently does.
This would require two enhancements.

First, a new field should be added to package.json, called versionStrategy, that allows a package publisher to indicate the version strategy in use, with enumerated values like semver (the default?), maven, dotted-numeric, dotted-alphanumeric, etc. This way, npm could determine whether a version string represents a prerelease versus a GA release.

Second, an option should be added to npm install called --allow-prereleases, along with its opposite, --no-allow-prereleases, where --allow-prereleases is the default, in order to preserve backward compatibility (but see note below). In the event that a package has published only prereleases, the explicit or implied version is @latest, and --no-allow-prereleases is given, npm install would fail, indicating that --allow-prereleases should be provided in order to allow the dependence on the prereleased package.

This request explicitly does not prevent the installation of transitive dependencies that are at a prerelease level, although that would be a nice addition. Perhaps, as part of this feature request, a new npm option could be added, called --allow-transitive-prereleases and --no-allow-transitive-prereleases, with --allow-transitive-releases being the default for backward compatibility.

NOTE: in a future major release of npm, npm install's behavior could change in a breaking manner by changing the default to --no-allow-prereleases and --no-allow-transitive-prereleases.

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

(I deleted a couple of posts where I was responding to this as a support question rather than as an idea.)

Could you give an example where the existing behaviour results in installing a prerelease version of a package?

I might be missing the point, as the only simple install situation I can think of which installs a surprise prerelease version is if the package publisher has tagged a prerelease version as latest. (i.e. the default install is of latest, which is a tag and not highest semver or most recent time.) Or is the main idea to support version strategies other than semver?

@shadowspawn Here’s an example: npm i --save @scispike/nodejs-support:

npm WARN lifecycle The node binary used for scripts is /Users/matthewadams/.asdf/shims/node but npm is using /Users/matthewadams/.asdf/installs/nodejs/10.14.1/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

> dtrace-provider@0.8.7 install /private/tmp/node_modules/dtrace-provider
> node-gyp rebuild || node suppress-error.js

  ACTION binding_gyp_ndtp_target_build_ndtp .
  TOUCH Release/
npm WARN saveError ENOENT: no such file or directory, open '/private/tmp/package.json'
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN enoent ENOENT: no such file or directory, open '/private/tmp/package.json'
npm WARN tmp No description
npm WARN tmp No repository field.
npm WARN tmp No README data
npm WARN tmp No license field.

+ @scispike/nodejs-support@1.1.0-rc.3
added 37 packages from 79 contributors and audited 42 packages in 11.087s
found 0 vulnerabilities

Note that npm installed 1.1.0-rc.3, the most recent release.

The crux of this feature request is evident in the second requirement:

That’s my point. It should be the exception, rather than the rule, to install prerelease software, even transitively. IOW, developers should be required to opt-in to get prereleases.

Perhaps I got you on the wrong track by discussing the versionStrategy attribute first. That attribute is only there in order to provide npm a means of comparing versions, with semver being the default. While many folks, myself included, use semver, it’s not the only versioning strategy out there, and for the requested feature to work properly, there’d need to be provisions for other versioning strategies.

Is that clearer now?

Thanks for info, and especially thanks for example project. I do like to understand the problem as well as the proposed solution, and potential work-arounds.

I have been doing some interesting research and will share more explanation and links when I have more time, but wanted to quickly share an approach that works with semver now and gives you the desired control, but does not make it the default behaviour.

$ npm install @scispike/nodejs-support
+ @scispike/nodejs-support@1.1.0-rc.3

$ npm install @scispike/nodejs-support@x
+ @scispike/nodejs-support@1.0.1

$ npm install '@scispike/nodejs-support@*'
+ @scispike/nodejs-support@1.0.1

I knew that latest was a tag, but hadn’t dug into what was possible. Very interesting problem @matthewadams. These do not negate your idea as such, but this might offer some new insights.

  1. First the default unqualified install from
npm install [<@scope>/]<name>

Do a <name>@<tag> install, where <tag> is the “tag” config. (See npm-config . The config’s default value is latest .)

In most cases, this will install the version of the modules tagged as latest on the npm registry.

  1. You can actually change what the default tag is:

  2. Using the version-range install from

npm install [<@scope>/]<name>@<version range>

and X-Range from semver:

gives us an install that does not include prerelease versions even if they were tagged as latest e.g.

npm install foo@X
  1. A great resource for trying out semver ranges is the npm semver calculator: