NPM On Windows
If you have been using NPM on Windows, you are used to
npm install -g installing packages under your user profile. It has a bin folder where it adds a batch file for each package that executes the main JS file of the package using Node.
You can check the path for this folder by running
npm bin -g. NodeJS installation would have added this folder to your PATH environment variable already.
It’s not the same on the Mac, and it’s by design.
NPM On Mac (Or any other Unix/Linux system)
If you go to the NodeJS official website and install Node from there on the Mac, then you run
npm bin -g, you’ll get an interesting result:
This is a root folder outside your user folder
~. This is why you are required to use
sudo (run as admin) with
npm install -g.
This is obviously inconsistent, but the NPM answer to this is that global installs usually mean “All users” install to *nix users.
Mac/Unix/Linux (*nix) Vs. Windows
So, why isn’t it the same on Windows? Because NPM seems to think that running as admin is a bit harder for Windows user and a surprise to users in a world where “per-user” installs are becoming more and more common. You can read the comments on the Github issue here.
The other alternative for Windows users if NPM were to standardize the approach is to have to open new console window as admin to install the global packages. There are probably other options but they’re even less common in Windows world.
Per User Or Per Machine
It’s interesting how things run differently in Windows and Unix/Linux lands. In Windows you are often granted with a good default that you typically change only if you have a reason to. In Linux/Unix land (including Mac), it seems how good the defaults are doesn’t matter. There will be a true defacto setting that is the real default, except you have to discover it on your own.
You can argue that Windows people are used to be dictated, or that the strive for better out of the box experience is better in Windows land. I’ll leave this one to you.
Although NPM use is much higher in *nix systems – I assume, most people will talk about NPM global install as per the defacto setting. Most people change the global bin location NPM config setting to a per-user folder, which they manually add to their environment path variable.
Some people run something like:
npm config set prefix ~/npm
And then add
$HOME/npm/bin to the environment path. Depending on whether you use bash or Zsh shell, you open your
~/.zsh and append something like:
Then you’ll have the global packages installed under your user account, and their commands still available everywhere in the shell, and you can manage them without having to use
Another Viable Option: Node Version Manager
When I posted this article on twitter I got a few comments suggests that the official install isn’t the best way to install Node anyway, even with the userprofile hack. That’s another difference to learn about Mac and Linux, there are sometimes more than single non-official de-facto way to do things.
Similar to Ruby for example, which has RVM (Ruby Version Manager), a version manager exists for Node as well. And it’s non-surprisingly called NVM (Node Version Manager).
NVM eliminates the problem with global installs as it installs global packages in a folder relative to the selected Node version, which happens to be a user-specific folder.
A side effect though is that if you are using multiple versions of Node, you need to install the global packages once per version (discussion).
Personally, I’m still leaning towards using the defaults and I just remember to use
sudo. I’m still new in this Mac world, and the main reason isn’t that I think it’s superior to Windows (actually I’ve got much more respect to Windows than what I already have form using the Mac), but to learn these nitty-gritty *nix life.
I might share more findings later as well. Stay tuned!
P.S. Please help me out by checking this offer, then look below for a small Thank You.
How did I learn that?
As a bonus for coming here, I'm giving away a free newsletter for web developers that you can sign up for from here.
It's not an anything-and-everything link list. It's thoughtfully collected picks of articles and tools, that focus on Angular 2, ASP.NET 5, and other fullstack developer goodies.