According to semver.org, there are conventions for pre-release and stable version numbers, but I haven't found conventions for NPM distribution tags. Since we can only apply a single NPM distribution tag with npm publish or with package.json's publishConfig.tag field, I am currently publishing distribution tags such that latest will be newer than alpha when we graduate our alpha packages.
Eg.
latest: 1.0.1
alpha: 1.0.1-alpha.0
Related
In the package.json of my reactjs webpack project I specified the version number of a dependency that I wanted to download through a npm install as ^0.0.130 where the latest version of that dependency is 0.0.145.
But when I hit the npm install its downloading 0.0.130, not the latest version.
But when I specified the version number as ^0.0.145 its downloading the latest version of 0.0.145.
I cannot figure out why its not downloading the latest version though i used caret sign (^) with the eailer number.
Can anyone help me to figure out why this is not happening in the right way.
^0.0.145 matches the most recent ^0.x.x version
To upgrade to latest version for the 1.0.0 major release you will need to use something like^1.0.0
Yes, That can be happen.
After a component is publishing using npm publish command the latest version is usually the highest version number. But if a component is published using npm publish --tag latest that version is marked as the latest one. So though you published new versions after that the latest version will be the eariler version.
In above scenario they published 0.0.130 as the latest version using npm publish --tag latest. So though they published new versions after that, ^0.0.130 is the latest one.
0.0.145
.......
.......
.......
0.0.131
0.0.130 --------latest
0.0.129
0.0.128
0.0.127
I'm trying to npm i --save and save the package installed as "*" (keeping to the latest).
Tried:
npm i --save something#latest
npm i --save something#*
And I'm out of ideas..
If you really want to have something#* or something#latest in package.json then instead of running npm install to put it there, you should just put it there yourself and then just run: npm install with no other arguments.
Keep in mind that it may install incompatible versions in the future. What npm puts by default is using semver ranges to make sure that you install only compatible versions in the future. If you test your code with e.g. version 1.2.3 then it should still work with 1.2.4 and probably with 1.3.0 but it most likely may not work with 2.0.0 - because in semver the ony reason for a major bump are incompatible changes - see: http://semver.org/
Semantic Versioning 2.0.0
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
How do I install the latest available version of an npm package? '#latest' sure doesn't fetch the latest - I assume it means the latest stable or something.
I've been using a hack for a while because I cannot seem to find any info on this:
npm i extract-text-webpack-plugin#X
The 'X' causes it to fail and dump all possible versions where I then copy and paste the correct one instead of the 'X'. Kinda ridiculous.
I've tried 3rd party packages like 'latest-version' but they all fail to get the very latest version.
There doesn't seem to be an official to do this. For example at the time of writing the latest version of extract-text-webpack-plugin is 2.0.0-beta.4. However doing:
npm i extract-text-webpack-plugin#latest
Will install '1.0.1'
I can see the latest version by doing
npm info pkg versions --json (without --json it will cut off when there are many versions)
For lack of an actual tool I guess its going to be some grep work.
Version 1.0.1 is the 'latest' version of that package - published to the npm registry at least (tagged as latest)
From the docs for cli/dist-tag. Emphasis mine.
Tags can be used to provide an alias instead of version numbers.
For example, a project might choose to have multiple streams of development and use a different tag for each stream, e.g., stable, beta, dev, canary.
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.
By default, other than latest, no tag has any special significance to npm itself.
If you want the beta releases, then install from GitHub, or use the tags explicitly.
$ npm install webpack/extract-text-webpack-plugin
This is made pretty clear by reading the manual.
Even more clear:
latest is an implicit tag, attached to any published version of a package that was not published with an explicit tag (--tag).
Installing xyz#latest simply looks up the release tagged as latest in the registry. In the case of this package, that's release 1.0.1. That's it. There's nothing special going on here. #latest does not pull the most recent version published to npm
The versions listed as betas were tagged differently. Obviously none of them were tagged as latest, so trying to use #latest to get one is pointless.
From the registry:
'dist-tags': { latest: '1.0.1', beta: '2.0.0-beta.4' }
Again, use the GitHub releases for the bleeding edge, or use the versions/tags explicitly.
$ npm install extract-text-webpack-plugin#beta
Here you go, made especially for you:
recent-version
recent-version-cli
Condense this into a shell script, and you're good to go:
$ npm install extract-text-webpack-plugin#$(recent-version extract-text-webpack-plugin)
Use npm update as long as you have the package installed:
npm update <package>
I use npm to install some command line tools. Having the itch to always be up to date, I found the command npm -g outdated.
What is the difference between the columns wanted and latest?
The documentation states:
The resulting field 'wanted' shows the latest version according to the
version specified in the package.json, the field 'latest' the very
latest version of the package.
However I don't find it clear at all.
For example on my system I get:
Package Current Wanted Latest Location
cordova 5.3.1 5.3.3 5.3.1 lib
npm 3.3.4 3.3.4 3.3.3 lib
How can wanted be higher than latest? It seems to contradict:
the field 'latest' the very latest version of the package
Which version should I update to (I only use the command-line, not any node.js code)?
The wanted field makes no sense in the context of a --global run as there is no package.json to define which version you require.
Which version should I update to (I only use the command-line, not any node.js code)?
The latest version seems as a good choice if you like to live on the edge.
The wanted column seems like a bug, it is reported in github many times.
Update (after checking source)
The documentations seems a bit misleading so lets clarify:
The resulting field 'wanted' shows the latest version according to the version specified in the package.json...
As there is no global package.json, the version constrain used is '*' (set here).
Then the wanted version is the latest version of the package according to semver.
the field 'latest' the very latest version of the package.
Thats not true, what you get is the dist-tag "latest", that usually matches the latest version (see here). There are some packages that uses those tags to manage what get shown (like npm).
Which version should I update to (I only use the command-line, not any node.js code)?
It seems that the edge is wanted.
Update:
On my machine currently npm -g outdated shows:
Package Current Wanted Latest Location
babel-cli 6.1.18 6.2.0 6.2.0
generator-rise 1.7.0 2.1.0 2.1.0
npm 3.3.6 3.5.0 3.4.1
The version 3.5.0 exists as a release on github but has not yet been published to npm. So it is somehow getting picked up from there but glossing over the npm source I couldn't find any evidence to support this argument.
From the official documentation:
The resulting field 'wanted' shows the latest version according to the
version specified in the package.json, the field 'latest' the very
latest version of the package.
To elaborate:
npm allows you to specify a range of versions in your package.json, examples are available here. The maximum version that can be accommodated in the specified range is the wanted column.
This may be different from the version installed (if at all) because package.json may have changed in the meanwhile, or the author may have pushed a new minor release in between.
Considering your example, cordova#5.3.3 is marked as “wanted”, but “latest” is cordova#5.3.1 because npm uses dist-tags to manage its latest and next release channels.
npm update will install the newest version, but npm install cordova (with no semver range) will install whatever’s tagged as latest.
link to documentation
I was reading up on versioning with npm, and apparently it provides a nice convenient command for bumping your package versions.
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease]
prerelease
Lets say your package starts at version 0.0.0
npm version prerelease => 0.0.1-0
npm version prerelease => 0.0.1-1
Basically just bumps the number after the dash
prepatch
Starting from 0.0.0 using pre[major|minor|patch] instead...
npm version prepatch => 0.0.1-0
npm version preminor => 0.1.0-0
npm version premajor => 1.0.0-0
patch
Starting from 0.0.0 using patch...
npm version patch => 0.0.1
npm version patch => 0.0.2
I understand the rules for bumping major minor and patch versions, but what is the standard convention for versioning things prior to 1.0.0?
TLDR
I have not seen prelease versions utilized pre-1.0.0. It seems fairly pointless since the public API is not finalized yet. They become useful after 1.0.0 is released.
So when are prelease versions useful?
From semver.org:
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
and:
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. ...A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
The conventions I have seen pre-1.0.0 include using patches for bug fixes/typos and minor versions for any significant modifications. The conventions are less strict pre-1.0.0 since no public API has been guaranteed yet.
Prelease versions come in handy when you want to share some early features with the community.
For example, at the time of this writing, the latest stable release of npm-check-updates is version 1.5.1. Some of the new features I have added have introduced backward-incompatible changes, so to conform to semver I will have to release them under 2.0.0. Yet, I don't want to release 2.0.0 as the latest stable version until it has been more thoroughly tested by the community. Thus, I have published a prerelease version (using npm publish --tag unstable) versioned at 2.0.0-alpha.1. Community members can install the prerelease version (with npm install -g npm-check-updates#unstable) to try out the latest features while a normal npm install -g npm-check-updates will continue to install the stable 1.5.1 version for most users. When the prerelease has proven itself, I can easily publish it as the new stable at 2.0.0.