NPM Considered Harmless

Package managers have their issues, but you can - and should - use them

• Keith Ott
• Package Managers
• May 26, 2019
• 6 Minutes

Throughout my career, I’ve run into a handful of people that have the opinion that we shouldn’t rely on a package manager, such as NPM or NuGet. The arguments fall into three main categories: concerns over security, concerns over the long-term availability of package manager services, and concerns over it being easier to manage dependencies yourself.

If you have any of these opinions, let me be the first to tell you it’s okay to rely on package managers such as NPM or NuGet. And there’s a variety of reasons why.

The Decision Has Already Been Made

Virtually every software library you find today has installation instructions for NPM, NuGet, or any of the other multitude of package managers. At this point, package managers are an industry standard. If you want to avoid package managers, you’re spending a lot of time reinventing the wheel for a solution that the industry has already settled on.

And, yes, package managers have faults. For example, NPM has had its share of issues, from deleted packages breaking thousands of projects to malicious packages stealing cryptocurrency. But these issues are outliers; every day, millions of developers worldwide rely on package managers without issue.

Developers Rely on Others Already

Writing software assumes that the power company will be around long-term to power computers. Companies don’t stockpile diesel fuel for generators because if the power went out for good, society as we know it would collapse. It doesn’t matter if Uber can’t build their app if there’s no businesses to Uber to. Same goes for package managers; if NPM went down for good, we’d have much bigger issues since a lot of the web relies on it.

There’s the assumption that operating systems don’t contain malicious code. (Although there certainly have been attempts.) There’s the assumption that routers don’t contain backdoors. (Although there might be thanks to the NSA.) Unless you’re building a tech stack entirely yourself (including fabricating your own processors), at some point you have to trust others. This isn’t to say trust every “Free Hollywood Movies!” application you find online, but putting trust in widely accepted industry standards is a reasonable tradeoff developers make every day.

It’s Too Big to Fail

At this point, some very big tech companies with very deep pockets have their products tied very tightly to package managers. If NPM runs into serious issues with availability or security, I’m fairly confident Facebook will find a solution. If NuGet runs into similar issues, I’m fairly confident Microsoft will find a solution.

These package managers are too big to fail, and someone will step up to fix it. If not, we have much bigger issues, like tech companies large and small going out of business. We’re not just going to have issues building our software, we’re going to have world-wide economic depression.

You’re Assuming Nothing Else Changes

Worrying if you can build your project in 10 years is making the faulty assumption that nothing else will change.

Many of the platforms we write on today didn’t exist 10 years ago. Mobile app development was just getting started, and there was still a heavy amount of desktop development happening. Will you even still be working a React or Angular app in 10 years? What if WebAssembly takes off? What if we finally reach a Chrome monoculture and all development is done in Dart? There’s a good chance that your application will be rewritten or retired before package managers being retired is even a concern.

Furthermore, who’s to say the application is even needed in 10 years? Companies go out of business, companies get acquired, and companies change what market they’re focusing on all the time. (Of course, this isn’t to say some applications don’t live on for decades, but not all do. When was the last time you used Microsoft Encarta?)

It’s Easy

Another argument against using package managers is that it’s very easy to simply download the library you need from a website and include it in your solution. But I’d argue it’s far easier to use a package manager.

Package managers make it really easy to install libraries, especially if the libraries you’re installing have dependencies of their own. It gives you a single source to install from (you don’t have to Google and hope you found the official GitHub page), a consistent way to install it in your solution (so dependencies aren’t spread among five different folders by five different developers), and it handles installing the dependencies of the library.

Plus, some package managers such as NPM do automatic security auditing. They’ll tell you if there’s a security flaw in the version of the library you’re using, and easily allow you to upgrade. Plus, it’s very easy to immediately tell what version of a library you’re using, especially useful if you’re looking up documentation.

There’s also benefits for a new developer. If I’m hired at a company and told they use NPM for package management, I immediately know where dependencies are stored (node_modules) and how to install new dependencies (npm install). Not only does the company not have to train me, but the Internet has already documented their process.

Software engineering is all about abstraction and automation, and package managers do both.

Summary

Although developers will keep searching for one, the truth is there’s no silver bullet in software engineering. Package managers are no exception, and honestly, they don’t make sense in every situation. For example, if all you need is jQuery, a package manager probably adds more complexity than benefit.

However, to completely write off package managers due to concerns over security or longevity is a bit extreme. A large part of software engineering is making tradeoffs, and the potential drawbacks of package managers don’t compare to the real-world benefits you immediately realize by using them.

Back to Blog Posts

---

---

You may also like: