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.
Related
I am using nodist version 0.8.8 which is the latest one. By using this I installed latest node version 10.7.0 and latest NPM version 6.1.0. I assured it by reading the following document.
https://nodejs.org/en/download/releases/
Nw I surfed in Google to find whether NPM 6.2.0 is available? If it is I want to know the corresponding node version for it.
Node.js and NPM versions aren't directly connected, otherwise they would have matching versions.
Semantic versioning assumes that minor versions don't introduce breaking changes:
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.
This means that if NPM 6.1.0 works with Node 10.7.0, NPM 6.2.0 works with it, too.
Node version requirements are usually listed in package.json engines section, which can be checked locally or in GitHub repository.
npm package.json doesn't contain this section, so actual Node version that is suitable for it has to be deduced.
npm code base currently uses ES6 but no higher. Latest Node 6 release covers 99% of ES6 spec, it's expected that NPM 6.2.0 is fully workable with Node 6.14 or higher. Generally, it's certain that latest even major version (Node 10, as of now) doesn't have problems with latest NPM release.
You can use nvm which is node version manager
With nvm you have the option to install the latest npm compatible with your currently installed node
use this link to install nvm:
https://github.com/creationix/nvm
Node and npm are independent tools. You can very well install different versions of either.
Use
npm i -g npm#latest
to get the latest npm installed with your node.
use node -v and npm -v to get respective version informations.
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 have a npm module which is already released under 4.x.x version and have breaking changes comparing to 3.x.x stable version.
However I have some updates to 3.x.x version and want to patch its' npm version. Is it possible? Can I manage 2 major versions on npm?
Will https://docs.npmjs.com/cli/publish npm publish --tag do the trick?
However I have some updates to 3.x.x version and want to patch its' npm version. Is it possible? Can I manage 2 major versions on npm?
Yes, it's possible. Something that's common is to have the master branch for new developement and branch off older versions if you want to patch them and name them e.g. 3.x.
So if we assume your module has previously been released as 3.1.2 and you want to fix a bug, i.e. you want to publish 3.1.3 (patch release). Simply branch off from 3.1.2 (assuming you have a git tag v3.1.1):
git checkout v3.1.2
git checkout -b 3.x
# make changes and commit
npm version patch # will bump package.json, commit that and tag
npm publish
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