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
Related
If you're using node-sass you might get an error message like this when running npm install:
Downloading binary from https://github.com/sass/node-sass/releases/download/v4.13.1/win32-x64-83_binding.node
Cannot download "from https://github.com/sass/node-sass/releases/download/v4.13.1/win32-x64-83_binding.node":
HTTP error 404 Not Found
The cause of this issue is that in Node there's a concept called ABI (Application Binary Interface) which determines which native modules work with which versions of Node. Since node-sass contains native parts it requires bindings to make it work with different versions of Node. When trying to run npm install the installation fails when attempting to download a binding for your version of Node - which has a too high ABI version. In other words there is no binding for that ABI for node-sass
To solve this:
Uninstall Node
Compare ABI in the list at https://nodejs.org/en/download/releases/ and the mappings available at https://github.com/sass/node-sass/releases for the specific release that you're using
Download and install the latest version of Node which supports your version of node-sass
Delete the node_modules folder and run npm install
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.
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.
I have a problem with npm install {moduleName}
previously, all my sub-dependencies were installed under {projectName}/node_modules/{moduleName}/node_modules/
After I upgraded to Node v5.0.0 (via installer on website), all my sub-dependencies are installed together with the dependencies under {projectName}/node_modules/
Why is that happening? And how can I change it back to the previous behavior?
Node v5.x comes with npm 3.x. This is the intended behavior in npm 3.x. You can read more about it in the npm 3.0.0 release notes, but here's the gist:
Your dependencies will now be installed maximally flat. Insofar as is possible, all of your dependencies, and their dependencies, and THEIR dependencies will be installed in your project's node_modules folder with no nesting. You'll only see modules nested underneath one another when two (or more) modules have conflicting dependencies.
I'm not sure why you'd want the old behavior—it was a dependency nightmare, hence the change—but if you really want to you can downgrade to npm 2.x:
$ npm install -g npm#latest-2