when I install a new package in node js project with npm, without specifying a exact version, what is the package version going to install by default?
It would be the "latest" as indicated by the package information.
Source : https://docs.npmjs.com/cli/install
That is usually set as the latest stable release version, usually not the beta version and other unstable releases. But again, it all depends on each package, this is just some configuration information to be set by the maintainer(s) of the package.
Related
I have two versions of a package e.g.
#mycompany/mylob v2.0.0
and
#mycompany/mylib v3.0.0
version 3.0.0 has breaking changes from version 2.0.0 but we do not have the capacity to upgrade everything to 3.0.0 as of yet.
Another developer has upgraded an internal package e.g. #mycompany/utils to use version 3.0.0 and that is installed into our codebase so now we are getting compatibility errors when running the build as #mycompany/utils requires version 3.0.0 but the rest of the code in that repository wants version 2.0.0.
Is there a way with yarn/npm that I can install #mycompany/mylib v3.0.0 for #mycompany/utils and have the rest of the code refer to v2.0.0?
You can use custom alias installs:
npm i custom-name:#mycompany/mylib#3.0
You can change custom-name to any valid package name you want to use.
After that you can import the package with this alias name. e.g.:
require("custom-name")/ import * from "custom-name"
For npm install specific version, use npm install [package-name]#[version-number].
Say you get a warning in some libraries in a repo about security concerns from github. You want to quickly bump the version just to make the github warnings going away. You are not worried about re-installing, rebuilding and testing.
Is there a way to do this with npm?
npm update mypackage does not do anything.
Now it works different, if you notice package versions in package lock.json have a prefix, sometimes its ~ sometimes ^, they have big importance when it comes to package updating, as fixing package mismatches is the worst hell.
Suppose you have package in package.json called packX with version ~1.1.1 or ^1.1.1
When you run npm update for packX npm will first of all check the version prefix for it.
If there is ~ in this case it will be understood as install packX version >=1.1.1 and <1.2.0 so the highest version it can install can only be in range of 1.1.N, it will not go up to 1.2.N.
If there is ^ then it will be understood as >=1.1.1 <2.0.0 so the highest version that can be installed will be in range of 1.N.N but connot go up to 2.N.N
Hope My explication is clear enough, anyways you can check the docs for details
npm update will only update minor versions.
Eg: It will update version 1.2.3 to 1.5.2
But it will not update version 1.2.3 to 2.0.1 because there can be breaking changes.
To check new major releases of the packages, you run npm outdated
To update to a new major versions for all the packages, you can use npm-check-updates
npm install -g npm-check-updates
Then run ncu -u
This will upgrade all the versions in the package.json file, to dependencies and devDependencies, so npm can install the new major version. Now you can update packages to new major releases by npm update
Reference
There are 2 versions of node.js - LTS and latest current version. When using npm install to install packages, are the packages installed independent of the node.js being used? Do different node.js versions install different versions of the packages?
No they don't. When you install a npm package, it has its own version but of course package's version and node's version affect the usability of these packages.So, you need to delete old version of node from your system files. One more thing, please do not install npm packages global.Because when you do that, next time maybe you can use it in a other project but when it is updated by creater, you won't be able to have new updates and features or as I said before it can't be compatible with the new version of node.
I know it's possible to specify a minimum version of node for a package to allow itself to be installed without warning.
There is also a question about [installing only the latest version your package is compatible with and nothing newer.]
However, in my case I am trying to make my package be compatible with hardware that is not able to run versions of node newer than 0.10.x. Specifically, this is hardware using ARMv5 processors, for which support was dropped in newer versions of V8. To do that, I need some polyfills, for example, os-homedir. I don't want to actually require that any such packages are installed if not needed because they are marked as deprecated, and in the above example the npmjs page for it is marked as not even in use, although I currently am able to npm install it.
How can I specify that a particular modular is only required if the version of nodejs present on the system is 0.10.x or older?
What you are asking for is somewhat anti-semver, since you always have to install a specific version of your package. By calling npm install <package> you are simply asking for the latest version. Having npm roll back to older versions based on campatiblity might be confusing and not very "semver".
The current solution for this is the following:
Specify in your package.json the following:
{
"engines" : {
"node" : ">=0.10.3"
}
}
now installing this package on a version of node older than 10.3 will cause it to fail. The user then must run npm view <package> versions and then install the appropriate version of the package by running npm install <package>#<version>
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