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
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
How can I point to the master of a particular project repository using a node package.json? For instance, I am using karma-jasmine package in my project and is referred as "karma-jasmine": "1.1.0" in package.json. Now, the latest version of karma-jasmine is 1.1.1. But there is a bug which has been patched on their repository which is in the project's master branch. But it is not yet part of any release.
Could I by any means point to the master of the project repository so that I could have the access to the fixed code rather than waiting until they release a newer version? Is it possible at all?
Thank you.
To answer your question you can load from github directly by doing
npm install karma-runner/karma-jasmine
or
npm install karma-runner/karma-jasmine#branch
To your issue though, https://www.npmjs.com/package/karma-jasmine lists 1.1.1 as the current which matches the GitHub repo version for master and that is the latest commit.
So you most likely you can just do
npm install --save-dev karma-jasmine#latest
NPM modules are only available on the registry once they've been published there by their authors. If the project in question has merged the fix to master, but not yet published an updated release to the registry, there's no way for you to get it short of cloning their repo and building it yourself.
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.