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.
Related
I have a project that uses node.js 14.16.0. Both me and my teammember use that version.
I use npm 6.14.11 and my teammember uses npm 7.x.x.
This results in the package-lock.json being different; the lockFileVersion property is 1 on my PC but 2 on theirs.
I already use nvm and am considering to add a .nvmrc so everyone always uses the same node version, but this doesn't fix the npm version issue.
I believe that it is a good idea to use the npm version that the installed node.js version provides. If the next big LTS release uses a new npm version, the project will switch to that. But on NPM's site they say:
npm is a separate project from Node.js, and tends to update more frequently. As a result, even if you’ve just downloaded Node.js (and therefore npm), you’ll probably need to update your npm. Luckily, npm knows how to update itself!
Which makes me believe I should always update.
But they also say:
Node.js has lots of versions! To use Node.js, and therefore npm, effectively, you’ll want to make sure that you are on a version that is supported by the Node.js team. In general, you should use the version of Node.js labelled “LTS”.
Which makes me believe I shouldn't update and just use the one node.js provides.
What is the best practice?
npm has a concept of LTS. They used to tag a release lts so you could npm install -g npm#lts and get the latest lts version, but alas, no more.
npm will continue to support any major version of npm as long as it shipped with a version of node that is still supported. So they will support npm#6 until 14 goes EOL because npm#6 shipped with version 14.
That said, npm#7 is the current version of npm and it too will be supported on 14 as well for as long as 14 is supported.
If you don't want to force your coworker to update, npm#6 will continue to receive updates as long as Node.js 14 is supported. I would recommend updating to the latest npm#6 with npm install -g npm#6 though. Either version (npm#6 or npm#7) should work just fine. You just need to pick one with your coworker to avoid the package-lock.json churn (or not care about the lockfile churn).
tl;dr
Is there is a reason that I shouldn't do the following; Install and manage packages with a version of npm that is different (much newer) from the npm version that comes with the node version I am going to be using to run my app.
longer
Some context why I am asking. I have to work with a service that supports only node 0.10.32 (I know, don't ask) and an app that was written some time ago. We need to add some functionality and unfortunately when I try to run the codebase locally it does not because some dependency of some dependency updated the minor version and they introduced const or fat arrow notation (=>). We had used shrinkwrap to lock down the versions but something must have slipped.
I have spent days on this and at some point it came to me that the problem lies with the package manager not doing what I want. So I managed to install the packages I wanted and shrinkwrapped it using npm#3.10.10 which is what I get when I use node#6.12.3 (nvm use 6.12.3). And when I want to run the app I just switch to the node#0.10.32 to make sure that is going to work on the service.
Can anyone think of any problems with this solution or a reason I shouldn't do that?
Side question
I noticed that when installing node versions using nvm, they usually come with a specific version of npm? What is the relation of those versions? How are they decided? Was it the latest npm version along with that node version when it was released? Is it the latest version of npm that can run with that specific version of node?
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
I'm looking at couchbase library for nodejs how can I know with which version of nodejs is this library compatible with? does it match node version 4.4.4? is there a way to see different versions of this couchbase library and see one that suits node 0.12.x. and one which suits node version 4.4.4?
Unfortunately there is no official way of working this out unless it is explicitly mentioned in a file in the repository (most often the README.md).
For a lot of the larger modules however, there is an alternative, you can install the latest version with:
npm install <module>
Navigate to that module and run:
npm test
To make sure that the version is compatible with your current version. If there are errors, look to see if you can fix them, if they seem to be compatibility issues, simply downgrade the installation. E.G:
npm uninstall <package>
npm install <package>#1.5.0
I just installed the current version of node (3/14/16) 4.4.0 directly from Node.js via a Mac Package (the new suggested way, previously I installed via Homebrew).
I'm curious if anyone knows why the package ships with npm version 2.14.20, the book I'm going through suggests updating npm manually with the command
sudo npm install npm -g
The version I see is now 3.8.1, that's quite a large difference hence my question, is it safe/smart to be this far ahead of what Node.js is officially putting out with their Mac package file?
EDIT:
It appears it's common for Node's recommended v4.x install to come with npm 2.x, the question that remains is, will there be any negative side effects of using the newest npm but an older version of node?