Why do I have to care about npm/node version (running on machine/needed by project)?
Why does every project require a specific node/ npm version?
Where in the project is the required version noted (package-lock.json)?
Is something bad about requiring older version of node/npm?
Is it possible/necessary to upgrade project to run with latest versions?
Why do I have to care about npm/ node version ( running on machine /
needed by project )?
This question is very broad, I will try to answer it as precise as possible. Every version has certain addition/modifications/deletions in its modules. If you have a project that runs on Nodev16 it is also important to update the npm version(some minimum version) for compatibility with peer dependencies is important. Similarly, if we have a lower node version like v12, all the dependencies should be compatible with it like npm(to install dependencies with the same version)
Why does every project requires a specific node/ npm version ?
It depends on the project that you create. You can also update the versions of your project. There is a guide on how to update Node.js projects.
Is something bad about requiring an older version of node/ npm ?
Is it possible/ necessary to upgrade the project to run with the latest
versions?
Yes, you need to always update the older version to the current version because your project might be vulnerable to security loopholes or older version compatibility issues with a newer version.
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).
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 am quite new to NodeJS and am planning to upgrade NodeJS version for my current project. The most recent NodeJS LTS is installed using NVM.
I need to keep switching between the current LTS that i am using and the new LTS that has been installed. I understand that i can do 'NVM use' for this purpose. npm-shrinkwrap.json is being used to lock down the npm package dependencies.
I am planning to follow the below approach both in my dev machine and build machine;
Is it okay? If not, please suggest a best approach.
nvm use latest_LTS
Update the package.json to pick the version which is supported by
latest_LTS
npm install
generate testing_build
Whenever i need to generate a build for current release (with the previous LTS NodeJS)
nvm use currently_used_LTS
clear the node modules
npm install (Release npm-shrinkwrap.json)
generate release_build
Thanks
In theory that should work.
However have you considered the option of just doing a point release for the current release_build that does nothing except version-bump node?
You may find (after re-running your tests) that the latest version of node is backwards compatable with release_build (or only requires minor fixes), and you can simplify your life by porting everything to the latest node version, rather than constantly switching
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 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>