I'm currently setting up pre-releases (under the dev tag) for a new npm package of mine.
In my staging environment, I want npm to always install the latest pre-release version of the 2.0.0 version. Therefore, I specified "<packagename>": ">=2.0.0-dev.0" in the package.json, but npm somehow always installs the 2.0.0-dev.20180806T153307Z.3eaa718.HEAD, even if I do a clean install with removed package-lock.json.
According to the semver-checker my constraint matches the pre-releases published to npm.
I finally found the problem. Because there was no previous non-dev release published to npm for this package, npm always installed the pre-release version connected to the latest tag (see the image above in the question). The solution is to simply publish a fake release under an older version, e.g. 1.9.9. Now, a clean npm install works like expected.
Related
I can't seem to find information about how npm works with branches within a repository.
Suppose an npm package is currently versioned at: 1.0.5
A major change requires a version change from 1.0.5 => 2.0.0
Some users continue using 1.x.x to avoid breaking changes.
If a bug is discovered in 1.0.5 it needs to be fixed for the 1.x.x users requiring version change from 1.0.5 => 1.0.6
In effect, this is branching. I'd make a git branch for 1.x.x users and continue using git's master branch for 2.x.x
But how does this fit in with npm? Should I publish an older npm version 1.0.6? In that case doesn't 1.0.6 become the latest while actually 2.0.0 should be the default when doing npm install.
I can't find branch related information for npm. I'm sure the above is a common situation but I just can't find any info. Please can someone point me in the right direction.
You are on the right track - you want to publish package#1.0.6 without updating the latest tag. You can do this by supplying a --tag <tagname> argument to npm publish --
cd project
git checkout old-branch
grep version package.json
"version": "1.0.5",
[make changes]
git commit
npm version patch
grep version package.json
"version": "1.0.6",
npm publish --tag old-version
As long as you supply a --tag <tagname> argument to npm publish, the latest tag will not be updated, and people using npm install <package> or npm install <package>#latest will still get the 2.x version.
Note that the tagname has to share a namespace with version numbers, so it's best to choose a tagname that doesn't look like a semver version; avoid '1.0.6' or 'v1.0.6'.
Source: https://docs.npmjs.com/cli/publish
and: https://docs.npmjs.com/getting-started/using-tags
I am working on a project which has gulp as a dependency. I am looking at updating it to gulp 4. A quick look at the output of npm show gulp#latest shows
...
dist-tags:
latest: 3.9.1 next: 4.0.0
...
I wonder why the gulp team have left latest: 3.9.1 and choose next: 4.0.0, i.e. npm install gulp installs 3.9.1 while to get 4.0.0 one has to ask for npm install gulp#next. Why is the default version still 3.9.1? Is version 4.0.0 still not fully supported or something? I have not found anything regarding this on the gulp website.
From the npm dist-tag docs:
By default, the latest tag is used by npm to identify the current
version of a package, and npm install (without any # or
# specifier) installs the latest tag. Typically, projects only
use the latest tag for stable release versions, and use other tags for
unstable versions such as prereleases.
The next tag is used by some projects to identify the upcoming
version.
By default, other than latest, no tag has any special significance to
npm itself.
In this case latest is 3.x.x and next is 4.x.x As it is following semver, it means that there are backwards incompatible changes. If you check gulpjs.com, the link to the documentation brings you to the 3.x.x docs. It's the authorative version at the moment as set by the gulp maintainers.
I want to use latest distribution tag in my package.json for internal packages. This allows me to always get their latest versions when I npm install in local environment, without updating all external 3rd parties.
The issue comes when I'm hotfixing deployed verion:
For hotfix purpose I generate and save package-lock.json for each deployed version of the application.
But when I npm install during hotfix preparation, there is a conflict between versions of internal package in package.json and package-lock.json: package-lock.json points to version that was used in deployed application, but package.json point to latest distribution tag, which itself points to later version.
Since version specified in package-lock.json doesn't suit to version range specified in package.json (which is very specific - only the latest version will suit), npm install ignores package-lock.json and installs the latest version.
I searched through documentation and internet and didn't find any existing solution for the issue:
I didn't find any npm install flag that would treat package-lock.json versions with higher priority than distribution tag in package.json
I dind't find any tool that would reconstruct package.json from package-lock.json, or at least replace aliases (distribution tags) in package.json with specific versions from package-lock.json.
Is there any solution for my issue (besides writing a tool that will implement last approach)?
Sandbox:
https://github.com/maxlk/npm-lock-version-should-override-latest (clone and run npm install or its alternative)
I found a solution - to use npm ci instead of npm install.
It doesn't exit with error, despite the claim in the documentation: https://docs.npmjs.com/cli/ci
If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.
I just want some confirmation as I've always been using #latest for a while with my packages and want to know if I'm really installing a stable version or can possibly install a alpha/beta version of the package.
I'm pretty sure this is meant for stable versions as they tell you to install#latest for npm (unless it's special syntax like npm start).
The more I think about it, the more paranoid I get, any confirmation would be greatly appreciated. :)
Using npm install <pkg>#latest is equivalent to using npm install <pkg> by itself or listing * as the dependency version in package.json. npm documents this here:
npm install will use the latest tag by default.
So in practical terms, latest is semantically equivalent to stable.
However, if a prerelease version of a package is published to npm without specifying a prerelease tag such as --beta or --rc, that version becomes the latest by default:
By default, npm publish will tag your package with the latest tag.
As a result, it's possible to mess up and publish a prerelease version that will be installed by default. This happened to Bootstrap in late 2015.
This article from early 2016 by Mike Bostock explains how even specifying alpha or beta as part of the version number won't prevent npm from making that version the latest.
So unfortunately if you want to be certain that you get only stable versions, you need to monitor this manually or trust the package developers to always specify a prerelease tag for non-stable versions.
You can also view the tags assigned for a package like this:
$ npm view express dist-tags
{ latest: '4.16.2', rc: '4.0.0-rc4' }
I created a NPM module and I published it at version 0.0.1
I made some changes and pushed those to github, and I would like it so that when one uses npm install myModule the new version is used.
How do I tell NPM that there is a version 0.0.2?
Change the version in your package.json or use npm version <new-version>.
After changing the version number in your package.json, you can run npm publish to publish the new version to NPM.
npm install will install the latest version in the NPM repository.
Increase the version number and then run npm publish yourModule again - as described in the npm docs.
npm install yourModule will then install the latest version from the NPM registry.
I found the last answer a little misleading, sorry.
For me, updating the version in the package.json still resulted in the "You cannot publish over..." error.
The steps to resolve were (based on ops version number):
npm version 0.0.2
npm publish
If it is an patch release (small changes) use following:
npm version patch
It will increment the last part of version number.
If it is a minor release (new features) use following:
npm version minor
It will increment the middle part of version number.
If it is a major release (major features or major issue fixes) use following:
npm version major
It will increment the first part of version number.
From the npmjs documentation:
To change the version number in package.json, on the command line,
in the package root directory, run the following command, replacing
<update_type> with one of the semantic versioning release types
(patch, major, or minor):
npm version <update_type>
Run npm publish.
Go to your package page (https://npmjs.com/package/) to check that the package version has been updated.