I installed Node.js on Mac last year by just downloading it from nodejs.org. However, i have noticed that it is usually installed via some package managers like Homebrew(bad way) and NVM(good way). Question 1: Should i uninstall current Node.js and install it via NVM(which i don't even have)? Question 2: Is switching between Node version common? And why would someone do that?
Using NVM is a good idea indeed!!. There may be different projects that use different versions of NodeJs. In that situation, a library like NVM would be pretty helpful else you have to uninstall the old version and install the new one. You know how hard it is to uninstall and reinstall a new one each time you want to have a new version. Moreover if you want to try some new feature that is shipped in a newer version of Nodejs, you have to go through the installation/uninstallation process again.
So using NVM would create a sandbox like environment where one version on Node won't mess with another one.
Long story short, NVM would be helpful.After you install NVM, it's just a matter of doing NVM install 'nodeversion' and NVM use 'nodeversion' to use a particular version of Node.
Chances are you could be working on different projects which are based on different versions of node. nvm could help in this case.
It’s also very helpful if you want to verify whether your application works on different versions of node or not.
In general it’s nothing different with python2/3, different version of JDK, etc. You can stick with your current installation and switch to nvm only if it’s necessary. You will know when you need it.
Related
Hope to find you guys well =).
So, my problem is that I'm trying to initialize a Gatsby project and after some trouble I discovered that for some boiler plate "starter" template to work I would have to install an older version of Node. Since I already have nvm installed, I just downloaded the version I wanted and switched via terminal.
I verified it with node -v and it threw me the version I wanted. The thing is that when I try to run 'gatsby develop' it says "gatsby: command not found".
And that if I close and open my terminal again it resets the version. Is this supposed to behave like that?
By the way, you can already tell that I'm new at this so any information or guidelines will be of extreme helpfulness.
You can try doing yarn develop if using yarn. Or npx develop if using npx
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
So NPM 3 has removed automatic resolving of peer dependencies which is great, however in the scenario of developing a plugin/library to be consumed by an application elsewhere if I make the underlying library use peerDependencies which is the correct notion here, it means if anyone wants to work on that library they need to manually resolve all dependencies.
So rather than having them do that it seems logical that I could put the same dependencies into devDependencies to satisfy the local development scenario, so anyone consuming it would need to explicitly satisfy the peers, anyone developing the library further would get the peer dependencies for free via the devDependencies.
So the question is, is there anything wrong with that? as I can find very little info on how to sensibly handle peerDependencies in NPM3 in any automatic fashion.
=== Update ===
As mentioned in the comments, when I tried doing things this way it is not compatible with earlier versions of npm, so npm >= 3.0 work fine with this approach and it satisfies the criteria automatically for a developer to check out npm install and be productive, however if you were to do this on an earlier version of NPM it blows up around peer dependencies not met and does not seem to work.
I post this as I hope this incompatibility with earlier versions is somehow down to my incompetence in some way so I can both support ease of development for people who just want to npm install on this package to develop for it, but also previous versions. So if you know a better way or a way around this or other issues this introduces please speak up.
I was asked to post this as the answer so here you go:
As mentioned in the comments, when I tried doing things this way it is not compatible with earlier versions of npm, so npm >= 3.0 work fine with this approach and it satisfies the criteria automatically for a developer to check out npm install and be productive, however if you were to do this on an earlier version of NPM it blows up around peer dependencies not met and does not seem to work.
I post this as I hope this incompatibility with earlier versions is somehow down to my incompetence in some way so I can both support ease of development for people who just want to npm install on this package to develop for it, but also previous versions. So if you know a better way or a way around this or other issues this introduces please speak up.
Currently I am working on a nodejs project. I have installed Express 3.X which is in alpha stage, and my node version is also at 0.7.2-pre. I am currently trying to downgrade my express version, via npm, but it seems that i have to downgrade my node version as well.
What is the best way to achieve this? How do i down grade my node version. Thank you very much.
To easy the node version management you can use an npm package called n
There are tools that allow you to have multiple versions of Node installed - e.g. NVM - so you could do that.
However, to answer the question, you will need to re-install Node I'm afraid. Thankfully installing from source is pretty easy though a little slow. Just follow the installation instructions on the GitHub page.