7

I'm new to npm here, so maybe I don't get something. I understand that npm can install modules in an npm_modules directory that is local to the project, or by using --global you can install it in a machine-wide location.

Other than for some temporary convenience, why would you install any package globally? For example, I see all sorts of npm configurations / setups that do a global install of typescript. But if I have 5 projects on my machine and 3 of them use different versions of typescript, that is not good...right?

My experience with package management is from the Java/Maven world where all modules are installed in a global location (~/.m2/repository), but to reference ANYTHING (as a cmd/tool/plugin or as a dependency) you need to specify the version number. Thus you get the best of both worlds -- elimination of duplicate package installations and perfectly reproducible builds. I would have thought npm would, in its own way, accomplish the same thing.

What am I missing?

Dave
  • 21,524
  • 28
  • 141
  • 221
  • 2
    Yes, it's a bad practice. Repository-level installment is preferred. – Tamas Rev Oct 03 '16 at 14:11
  • FYI - running a "tool" from a local repository is doable: http://stackoverflow.com/questions/9679932/how-to-use-package-installed-locally-in-node-modules – Dave Oct 03 '16 at 15:28

3 Answers3

9

If you are working with multiple tools for transforming your code (Typescript, webpack, babel) and you intend to work with different packages locally and link them together, I would definitely NOT recommend installing things globally, you will suffer a lot when updating any global component. Even webpack team discourage installing globally the second version:

The webpack command is now available globally.

However, this is not a recommended practice. This locks you down to a specific version of webpack and might fail in projects that use a different version.

Community
  • 1
  • 1
Paulo Madroñero
  • 320
  • 4
  • 14
6

The npm 1.0 release notes clarify this rationale:

In general, the rule of thumb is:

  1. 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.
  2. 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.
msanford
  • 11,803
  • 11
  • 66
  • 93
  • 2
    I think this summarizes the current state of how it is used. But like @jwenting answer, aren't we assuming here that different versions of tools don't produce different final artifacts. Is tsc v1.8 100% guaranteed to produce identical output as tsc v2.0? Or am I just being a pedant because in the end, we have a CI server that has the final say.... – Dave Oct 03 '16 at 14:21
  • Perhaps, but pedantry can often be an asset in software development. To your point: you are _definitely not_ guaranteed that different major versions of any tool or modules will produce the same output. If you have tools (such as `tsc`) that are installed globally, simply put a step in your CI to update or synchronize your module versions at some reasonable interval. In practice, I have never had an invisible build issue related to this sort of problem. In the case of bugs, your tests (or tsc itself) will/should complain loudly and indicate the problem pretty clearly. – msanford Oct 03 '16 at 15:05
2

Maven installs nothing globally. It keeps a local "global" repository to prevent having to download everything for every new build, but every project has its own versions of all libraries you define in its pom file.

For npm, typically you'd install some tooling using it globally, like grunt-cli and karma-cli, then in the package.json for each project define which modules/libraries are needed in which version for that project.

jwenting
  • 5,505
  • 2
  • 25
  • 30
  • But lets say I globally install karma-cli with version 1.0 and you have it globally installed with 2.0, and our CI server uses version 3.0. Isn't it possible that we'll get different results when we run it? I get that it is just a tool, but something tool versions produce different results. – Dave Oct 03 '16 at 14:18