Are there any issues or side affects to installing node modules under a particular Node.js version, changing the version of Node.js (eg. with NVM or a general node upgrade), and using the previously installed node modules?
Yes there are! If I install a module tested against a certain version of node and thereafter I update my node version, I can’t guarantee that the module will still work as expected.
There is an optional field engines that can be set in the package.json; from here, the module publisher can specify the version of node needed for his module to work, e.g.
{ "engines" : { "node" : ">=4 <6" } }
This will send a warning message during the package installation if your node version is not supported.
Related
I am trying to lock node and npm version in my javascript project to ensure other developers have those specific versions when building bundles to commit. I just added this to my package.json:
"engineStrict" : true,
"engines": {
"node" : "10.10.0",
"npm" : "6.5.0"
},
Will this enforce those versions definitively? I am unfamiliar with locking down versions since I am used to be the sole developer on frontend projects or inheriting projects that have had this set up.
Alternatively, is there a benefit of also adding an .nvmrc file that specifies the same version or is that redundant if I'm using engines?
Enforcing Node.js version
engineStrict is deprecated since npm v3, but you can set engine-strict=true in your .npmrc file. If you have engines set in package.json, an error will be thrown when someone installs on an unsupported Node.js version.
.nvmrc for developer convenience
To make it easier for other developers to use a supported Node.js version, you can add a .nvmrc file. Now other developers can run nvm use to automatically use a supported version.
I tried to upgrade my Node version, I downloaded the file from their website, run through the installation and everything seemed OK.
When I tried to check if the latest version has been installed, node -v showed me v7.7.4 instead of v8.4.0.
I tried brew upgrade node but it told me node 8.4.0 is already installed.
How do I switch to the latest version?
Thanks!
You're using nvm to install multiple versions of Node.js, and it looks like you set 7.7.4 as the default version of Node that nvm should use, which means that even though the system-wide version of Node is 8.4.0, nvm will insert the path to the 7.7.4 executable earlier in $PATH.
You can change the default to point to the system-wide version:
nvm alias default system
FWIW, Homebrew (brew) is yet another method of installing Node. However, given the amount of issues I see being posted here on StackOverflow related to that particular install, I wouldn't advise using it. Use the official installer to install the system-wide Node, and use nvm to manage different versions (for instance, to test your code with).
you can check your installation directory
Command : 'where node '
When working on Meteor 1.3 projects, should I always prefix npm with meteor? In the Meteor documentation and in code examples I see both.
I suspect that I always want to do this:
$ meteor npm install --save some-package
But is there ever a situation, in a Meteor project, where I want to just use the system npm?
$ npm install --save some-package
Are people just using shorthand when they omit the meteor prefix?
Well, to be exact, it depends on what you want to perform.
The easy rationale is based on what Tom did not explicitely say in his answer:
$ meteor npm install … will use the local npm shipped / bundled with Meteor Tools. It is the official supported version for Meteor.
$ npm install … will use your global npm, which version might differ from Meteor's one.
In the case of npm, the difference might be unnoticeable.
Unfortunately, the situation is different for Node: Meteor 1.3 still relies on Node 0.10.43! Simply give a try with commands $ meteor node --version and $ node --version.
Meteor 1.4 is supposed to upgrade to Node 4.
Knowing that, you can still use $ node (without meteor prefix), as long as your script does not need to be executed later on by Meteor itself (typically through a build process). Even if it does, you should not have troubles if your script does not use advanced Node features (i.e. introduced after version 0.10.43).
At least there is no difference in using a global npm or the meteor encapsulated. For me, I always use meteor npm or meteor node because I do not need and do not want to install global software.
Also to know, the bundled node is always the release with best tested compatibility and so I always use that. Also on production environment, we have installed meteor and use the bundled npm and node when running our apps. No issues by now.
I also like to have all project related stuff inside the project folder and not globally. That means, that we do not install anything npm related globally but always local to the node-modules folder.
This gives us the opportunity to move and run our software on different self hosting environments without headages or compatibility issues even between projects with different releases on same system.
Be aware that before release 1.3.4.3 the meteor tool does not respect always latest tools but this is solved by now.
Cheers
Tom
I have multiple Node.js versions on my computer, and i'm using n to switch back and forth between versions.
When i'm using version 4.0 which is the first version that I've installed i can use the following command to list all the globally installed node modules :
npm list -g --depth=0
Whereas when using 5.x versions like (5.0.0 or 5.2.0) i get a an empty string, meaning that there is no global modules.
I've also tried to get the path to global modules under version 4.0.0 and higher using the following command :
npm root -g
and surprisingly it was the same path.
What i can't grasp here is how can it come that they share the same path and i'm getting different results in different versions.
Any suggestion is appreciated.
This a bug in npm version 3.5.3 which comes with node 5.x. You can read more about it here: npm can't list global packages
You can view all the installed packages by executing ls on the root directory.
Server: Ubuntu server 14.04
Node: v4.2.6 LTS
npm: 1.3.10
I pullled my colleage's work from git remote. He made the node_modules as .gitignore. So I have to npm install the modules.
But after a successful install of npm. when I try to start the project using mocha. It remind me of a module didn't self-register
The error comes from the module of Bcrypt.
at bindings (/base_dir/node_modules/bcrypt/node_modules/bindings/bindings.js:76:44)
I don't want to downgrade my node to 0.10, because, I can't use JS promise in that version. Somehow, JS promise is a must in my work
This problem happens mostly because you copied/cloned the repository from somewhere else, but some modules for nodeJS should be installed/registered locally on your machine, during which the happens the build process(maybe some native language like C).
and be noted that the node_modules folder should not be staged for versioning. and should be ignored by versioning tool. and the one who is trying to clone this package should build / install firstly.
I find the answer to this problem.
But plz don't devoted this just because you want.
I upgrade the NPM using
npm install npm -g.
after that, delete the node_modules folder,
then,
npm install
Everything will be good.
I had this issue while setting up my Cypress project.
After trying to delete and then reinstalling all the node-modules and upgrading everything I found out the issue was caused because Cypress uses node from its bundle version by default (which was version 8.0 in my case) , whilst the package I wanted to use required the node version to be 10 or higher.
I did have node 12.0 installed on my machine but since cypress was not using that I had to add the line shown below in the settings file (cypress.json) to set the value for 'nodeVersion' to 'system', this way you are telling cypress explicitly to use the node version installed on your machine.
Add this line to your settings file:
**"nodeVersion": "system"**