2

I just setup a test, and tried to npm install express even though express already exists globally on my system. To my surprise, instead of using the global version, it ended up re-installing a version locally!? Isn't it supposed to use the global version... Or am I suppose to use -g every time, even when I only want to use the existing global version. Otherwise, what's the point of installing anything locally!?

Grateful
  • 9,685
  • 10
  • 45
  • 77
  • 1
    I'd ask the reverse question: what's the point of installing anything globally? The point of a local install is so you can have separate sets of installed packages for each project. That helps avoid forgetting to add a package you need and makes sure everyone else will have the package installed as well (especially your build server). – jpmc26 Oct 05 '16 at 04:01
  • because if you are working on multiple projects locally... you end up having to redundantly install many modules again and again. It's better to install it once, and use that installation several times. – Grateful Oct 05 '16 at 04:16
  • I don't understand why this question is getting minus points... it's a genuine question, and I sincerely want to know the answer. Is that too much to ask around here? – Grateful Oct 05 '16 at 04:18
  • 1
    Global and local installs are meant to serve different use cases. From [npm's `folders` document](https://docs.npmjs.com/files/folders): "*• Install it **locally** if you're going to `require()` it. • Install it **globally** if you're going to run it on the command line. • If you need both, then install it in both places, [..]*" – Jonathan Lonowski Oct 05 '16 at 04:35
  • @Grateful Better how? Because it saves disk space? On the flip side, the cost of installing it globally is creating work for yourself. You will make more mistakes managing the dependencies of each project that way, and will have to spend time fixing it. You will also annoy other people on the project with those mistakes. You will quickly find that software is very much a game of trade offs; the vast majority of developers have come to the conclusion that the hassle created by installing packages globally is simply not worth whatever benefits it provides. – jpmc26 Oct 05 '16 at 05:15
  • I think you misunderstood my position. I was not vouching for either. Both make sense depending on the situation. For instance, when you are working individually and not in a group... global installations make more sense. – Grateful Oct 05 '16 at 06:32
  • This question is really worth it. At least newbies can understand the importance of local installation. – Sapthaka Jan 03 '22 at 12:48

2 Answers2

2
  • If you’re installing something that you want to use in your program, using require('whatever'), then install it locally, at the root of your project.
  • If you’re installing something that you want to use in your shell, on the command line or something, install it globally, so that its binaries end up in your PATH environment variable.

The first option is the best in my opinion. Simple, clear, explicit. The second is really handy if you are going to re-use the same library in a bunch of different projects

Install locally-

npm install moduleName

install locally and save in package.json- 

npm install moduleName --save

install globally-

npm install moduleName -g
Anshuman Singh
  • 1,134
  • 1
  • 13
  • 21
  • Thank you for that. But I guess, I was really asking why it wasn't looking at my global npm modules, before installing it locally. However, I already have a better understanding. Thanks once again. – Grateful Oct 05 '16 at 06:35
  • I have just arrived here and, after reading the whole thread, It is clear both pros and cons, but, since we are software developers, to develop a new checkpoint before deciding to install or not a given package if current global installed package in the machine matches package.json specs won't hurt anyone, right? – Ton Dec 19 '22 at 12:57
2

The answer is "NO". It isn't supposed to use your global version.

If you want to use your global version, then you doesn't need to execute npm install at all because it is already installed.

If you do it then, obviously, you are saying "I want to install it locally to my project". And more than that: "I want to install its latest version unless it is declared in my package.json with other explicitly specified version".

In fact, the actual question is: Why in the hell would you want to not install a dependency of your project locally? To have more version mismatch issues?

As @anshuman_singh says, best practice is to always do an npm install --save.

You are able to use globally installed packages, of course. It could be handy for fast testing code that you will drop just after a few hours or so.

But, anyway: If you doesn't have really hard disk or network bandwidth issues, installing all dependencies locally will avoid you too much trouble in the future.

On the other hand, uploading that modules to your code repository is also a bad idea (maybe that is what you were trying to avoid) because, with different versions of node, most native modules won't work if not rebuild. But most VCS support ignoring files and or directories that must not be uploaded.

For example, in git (.gitignore file):

**/node_modules

In summary:

  • npm init (if you didn't already it).
  • npm install --save for all your project dependencies.
  • npm install --save-dev for dependencies not needed in production (testing stuff).
  • Don't upload node_modules to your VCS.
  • After new checkout: npm install or npm install --production (to not install dev-dependencies).
  • npm install -g only for tools you will use in console.

This way, you are sure that you will have in production (or other dev environments) the exact same version of each package.

And, finally, if you ever want to upgrade some package to its latest version, simply run:

npm install --save <pagkage_name>@latest.
bitifet
  • 3,514
  • 15
  • 37
  • Thanks for your comment. Also notice the edit (just now) adding 'npm init' note: You should do it if you haven't already the *packate.json* file. Without this file *--save* *--save-dev*, etc... won't be able to store your package list and versions. – bitifet Oct 05 '16 at 06:44
  • 1
    Once again, thanks. Also, I presume you mean package.json and not packate.json. – Grateful Oct 05 '16 at 07:18
  • No worries. I have a much better understanding now, thanks to you guys. – Grateful Oct 05 '16 at 07:21