By Any chance is there anyway to check, node version and add dependencies accordingly.
For example in SPA, How I can check if node version-8, then during NPM install refer to "package-name":"8.0.1"
IF Node Version 10, then NPM INSTALL should refer to "package-name":"10.0.1"
If Node version 8, then NPM INSTALL should refer to "package-name":"8.0.1"
NPM supports an engines field in package.json. For example:
{ "engines" : { "node" : ">=10.3 <12" } }
Means that a package works on Node versions higher than 10.3 and lower than 12. When NPM performs package resolution it will attempt to use that field and resolve packages for you.
You can define your own package anup-dep-installer and publish two versions of it - one for Node 8 and one for Node 10 (specify the engines field). When you NPM install it it should pick the right one correctly.
Note that you shouldn't have to do this if the packages specify this automatically - and it is an extremely bad idea to include different packages on different node versions normally for anything other than compatibility reasons.
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 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>
Here is an example command for installing npm v2 instead of latest (which is v3):
npm install -g npm#latest-2
How does this syntax work?
Usually I use either latest or explicit version, but haven't seen such syntax before.
I've tried something similar with other packages, for example:
npm install express#latest-4
but it fails with error No compatible version found: express#latest-4
These are called tags, and they're intended to allow developers to label particular versions of their packages in a more human readable way.
By default, all versions are tagged as latest, but say you have a beta version that you want some users to test - rather than making them specify a particular version to install, you can tag your betas with npm publish --tag beta. This will then allow them to run npm install mypkg#beta to get the latest beta version.
You can also tag a version after you've already published by using npm dist-tag add <pkg>#<version> [<tag>].
See https://docs.npmjs.com/getting-started/using-tags for more info.
I've installed nodenv to manage versions of node and npm in my pc. Because when I try install packages like , angular-cli, webpack , typescript, angular2 and another, I get errors
FIRST QUESTION: Can an version node or npm produce error when i install a package?
Some packages tells things like: "The generated project has dependencies that require Node 4.x.x and NPM 3.x.x."
but they don't mention the exact version. by example Can a version of node 4.1.5 produce errors and not the version 4.0.5 ?
SECOND QUESTION:
I don't like these packages need be installed like global (-g) and the problems i see sometimes there are conflicts between global packages installed.
Example error:
npm WARN EPEERINVALID string-replace-loader#1.0.3 requires a peer of webpack#1.x.x || 2.x.x but none was installed.
PhantomJS not found on PATH
Downloading https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-macosx.zip
but what about if two global packages use same global package, but some of they use a different version for every package?
Its up to npm package owners to define in their package.json all the upstream dependencies with a set of working versions which play well together ... challenge is as a package owner to make your package.json loose as possible regarding upstream dependencies to enable pulling in newer releases of these dependent packages yet tight enough that your published package still works
Often this is not the case which can lead to version mismatch invoked errors ... if possible always use most recent package releases this goes for nodejs itself as well
When package.json mentions versions such as 3.x.x it means it should work with any value of x.x so just chose the highest number to fit the pattern
Where possible avoid doing a global install unless it is for command line executables ... this is especially true for packages which your code pulls in as opposed to an executable centric package
UPDATE I am now able to successfully install this
npm install -g angular-cli
using the latest release of node
node --version
v6.5.0
so I suggest you upgrade your own project code and node version to avoid that pinned release which fails and work with the most current releases
See title. I searched all across the internets and could not find a firm answer.
The reason I want to use npm3 is because I am working in a Windows environment and I am hitting the dreaded too long path name. Migrating off Windows is not a viable option at this time.
Also, I can not upgrade to node 5.x because I use the karma test runner, which is not yet supported on node 5.x
So, I want to use node 4.x with npm 3.x.
I have successfully updated my machine, using the slick npm-windows-upgrade package, to use npm 3 with node 4.
After the upgrade, I did see a couple issues with karma not realizing jasmine/phantomjs was available. The workaround was simply to install both those packages locally.
Yes. The npm 3.x is compatible with node 4.x.
In fact, any node >= 0.8 is okay.
This has been documented in
https://www.npmjs.com/package/npm#important
You need node v0.8 or higher to run this program.
And more, I suggest you to use the nvm
https://github.com/creationix/nvm
It very easy to switch in various node environments with nvm.
Your jasmine/phantomjs is references by peerDependencies, npm 2.x will install it if missing, and an error will be reported if found version conflict by multiple package.
As you known ,the npm 3.x flatten the package dependencies, peerDependencies will print a line of warn message only(will not be instal), you should manually include peerDependencies in your package.json file, this means it is you that decide which version should be installed.