-
Notifications
You must be signed in to change notification settings - Fork 100
Installing global node modules (Linux and Mac)
If you try to run npm install some-module -g and you receive npm ERR! Error: EACCES, here are some options
On many operating systems the default npm prefix, which is where npm will put global modules, is in a folder that requires superuser privileges to write to. You can use sudo (superuser do) to give npm these permissions.
If you run npm install some-module -g and receive and EACCESS error, you can try running it again with sudo in front, like this:
sudo npm install some-module -g
You can run this command to change the npm prefix, which is where npm will put global modules
npm config set prefix=$HOME/node
Then, edit your .profile or .bashrc file to add this command:
export PATH=$HOME/node/bin:$PATH
Now, every time you log in or open a terminal, it'll run that command to update the PATH environment variable. If you don't want to re-load that file, you can run export PATH=$HOME/node/bin:$PATH right in your terminal, and it'll do the same thing.
If you're logged in as someuser then $HOME will usually be something like /home/someuser, so this will set npm's "prefix" setting to /home/someuser/node. npm installs executables in the bin folder under the prefix, so you need to add that to your PATH environment variable so that when you run a command, the system can find it.
The $HOME directory is a folder where you have permission to make changes. Things like configuration files and other user-specific stuff goes in there.
There's nothing magical about $HOME/node, per se. You can use any folder name there you want. But this way, everything npm installs will be in that folder, and if you ever need to delete it or move it or just go digging around for education, you can do that.
When you run the npm config command, it edits the file at $HOME/.npmrc, which npm looks up to get configuration settings every time it runs. Take a look at that file, and you'll see how it does this. (This is also where it stores stuff like your token when you log in to publish packages.)
The PATH environment variable is how your computer knows that running something like vim should actually the program that lives at /usr/local/bin/vim. If you type which vim, you'll see what this resolves to. On Unix machines, the PATH is a :-separated list of folders that are searched for executable programs. You can see what your PATH is by running echo $PATH.
npm is designed with the most common use-cases in mind. Most of the time, that means, "I'm installing stuff right on my laptop, or on a server I own, so I can sudo what I need to, and I want to keep 'global' bins in a 'global' place, which usually means somewhere under /usr/local." Defaults aren't perfect, but the "least surprising" approach is usually to follow the conventions of other Unix programs, so that's what it does.
However, if you're on a VM or something, or if you can't or just don't want to use root for some other reason, then you can tell npm to do a different thing, and it'll obey you, because you are a human who can modify configurations to set up the machine how you want it.
Another option is to change the ownership of /usr/local so that you have permission to write stuff there. This requires root (administrative super-user) privileges, so it might not be an option in a VM hosting environment, or for other reasons. You can do that with this command:
sudo chown -R $USER /usr/local
Depending on the flavor of Unix that you are using, this may or may not have other ramifications.
I personally do this on my laptop, because I'm the only one who uses this laptop, and it's a computer that I own and touch with my human hands, so if I break something, oh well, I'll be the one to figure out how to fix it. I don't mind breaking things on my laptop, because I usually learn something by fixing those things. But it is sometimes inconvenient to have to fix things that I break, so be advised that you may be entering a world of google searches, asking questions, and potentially frustrating learning experiences.
Keep a file of notes of each thing you change that you aren't entirely sure of, and be very diligent about recording each step. This way, if one of those changes breaks something, you can use those notes to figure out what might have gone wrong, and if you have to ask someone else for help, you can explain how you got into this state. Most of the time, that is the first thing they'll ask if they want to help you.
There's usually no need to install something globally. In fact, it can be a bad idea, especially if you have a bunch of different projects that need different versions of something. If your tests in one project needs a different version of the test runner than another project, then it would be really annoying to have to re-install a different version each time you switch to working on something else!
To do this, just use npm install <whatever> in your project folder, without the --global or -g flag. Then, the executable program will be installed in ./node_modules/.bin/<whatever>.
If you run your tests by adding something like "scripts": { "test": "tap tests/*.js" }, then it might look like this has to be installed globally. However, when you run npm test, it'll add node_modules/.bin to the PATH environment variable for you, so that it finds your locally installed package.
You can add other scripts to your package.json file, and run them with npm run <script name>, so that it'll see local installs first on the PATH. Then you never have to install anything globally.
If you save your test runners and other things in your devDependencies field in package.json, then you will get them loaded by typing npm install. You can have npm do this for you by installing them with the --save-dev flag. For example, npm install gulp --save-dev.