The Node Package Manager (a.k.a. npm) has given web developers easy access to a lot of awesome JavaScript modules and has made our lives considerably easier when trying to find and manage dependencies for our applications. It also makes it easy for developers to create and publish their own modules, meaning that other developers can grab them with a simple npm install -g your-tool and start using them any time they want to. It’s utopia! Right?
Err, actually …
We’ve Got a Bit of a Problem
I will never say never use the -g option when installing an npm module, but I do have to say that we are causing problems by using it too much. There are a couple reasons that I think we should cut down on our use of global module installation, especially in the case of build, test, or linting tools such as Gulp, Karma, JSHint, and countless others. I’ll be referring primarily to Gulp throughout this article because it’s quite popular and it’s fun to say, but if you don’t like Gulp, just mentally replace it with whatever you prefer.
First of all, global modules are not listed as dependencies in your projects, even though your project depends on them, which causes extra steps for others using your application. You know that you need to use Gulp in order to get your project ready for production, so you install it globally and use it. When someone else wants to start working on, or using your wonderful open source project, they can’t just type npm install and get going. You end up having to throw directions into your README file saying something along the lines of
To use this project, follow these steps:
git clone the repo- Run
npm install
- Run
npm install -g gulp
- Run
gulp to build
I see two issues with this: firstly, you are adding the extra step of installing Gulp globally and secondly, you are running gulp directly. I see an extra step that could have been avoided (globally installing Gulp) and I see that the user is required to know that your app uses Gulp in order to build the project. This first issue is the main one I’m going to address in this article, and although the second one isn’t as big of an issue, you’ll need to update the instructions if you end up switching tools. The solution I discuss later should fix both of these issues.
The second big issue relating to installing modules globally is that you can run into conflicts due to having the wrong version of the module installed. This is illustrated by the following two examples:
- You created your project six months ago and you used the latest version of Gulp at that time. Today, someone has cloned your project’s repo and tried to run
gulp to build it, but runs into errors. This is because the person who cloned your project is either running an older version or a newer version of Gulp that has some breaking differences.
- You created a project six months ago that used Gulp. Since then you’ve moved on to other projects and updated Gulp on your machine. Now you go back to this old project and try to run
gulp and you experience errors because you’ve updated Gulp since the last time you touched the project. Now you are forced to update your build process to work with the new version of Gulp before you can make any more progress on the project, instead of putting it off until a more convenient time.
These are potentially very crippling issues. Like I said earlier though, I wouldn’t make a blanket statement telling you never to install something globally. There are exceptions.
A Brief Note on Security
By default, on some systems, installing a npm module globally requires elevated privileges. If you find yourself running commands like sudo npm install -g a-package, you should change this. Our beginners guide to npm shows you how.
Continue reading %How to Solve the Global npm Module Dependency Problem%
by Joe Zimmerman via SitePoint
