NPM dependency hell


Today I want to share some thoughts on the current state of NPM packages infrastructure. I’m pretty sure that NPM is very good thing:

  • It’s easy to use. Seriously, I love the way it’s working. Recent changes, like adding package.lock.json are making NPM better and better every day;
  • It has a good community and it’s very popular. You can literally find everything that you need here;

However I’m a bit disappointed in the current state of dependency graphs for most of the popular packages.

I’ll take an regular Angular application as a sample. What we have as direct dependencies:

  • @angular
  • @angular/cli
  • @ngrx
  • rxjs
  • typescript
  • tslint
  • codelyzer
  • zone.js
  • core-js

And that’s it. Looks pretty straight forward. And now let’s install all the dependencies by typing:

npm i
... one eternity later ...
added 1174 packages in 116.846s

Seriously? 1200 packages and 2 minutes to install. package.lock.json contains 11000+ lines of code (don’t try to convince me that’s I should not worry about it, because sometimes I do, not every single day, but sometimes I need to look trough all the dependencies and understand where everything went bad on production). Let’s try to understand what’s happening inside:

  • The first reason is that a lot of packages have redundant dependencies. It’s 2k18 right now, why do I need to support IE6. It’s not killer feature anymore, if someone still need to support IE6 it should be his own problem in my opinion, there are plenty of polyfills available in the NPM, but they should be installed on-demand, not to everyone. I’m writing Angular application and Angular itself does not support IE6 (indexof, isarray);
  • The second and unfortunately most important reason – bicycles (or invention of wheels). There are literally thousands of packages doing absolutely the same stuff. There is no moderation in NPM as a result to publish your own bicycle to the NPM you need to be smart enough to get a unique name and that’s it. What I have in the Angular’s dependencies:

I’m pretty sure that this code was written with a good intend, however that’s how good intends are always over. If you want to publish new package to the NPM, please, don’t do it. Stop for a moment, try to find packages with similar functionality, consider contributing to most popular package, make it more popular by providing better functionality, API, documentation, by removing less popular packages from dependencies of other packages. This will help to reduce size of node_modules and package.lock.json. This will make world a little bit better!

Thank you! That’s all I have for today.

4 thoughts on “NPM dependency hell

  1. I think current state of things has several reasons: 1.) lack of documentation and information about already existing packages 2.) desire to avoid some uncontrolled dependencies 3.) unclear scope and lack of centralization and standartization. But any demand to improve documentation or introducing some standartization immediately decrease the level of freedom and concurrency. The desire to have very limited scope to be widely applicable just increases the amount of packages. Also it is unclear how define the right scope of package.

    Liked by 1 person

    1. I completely agree with you, especially about documentation. There are hundreds of popular packages I’ve seen so far which have very limited documentation. Sometimes it’s not clear what kind of functionality they provide…

      Like

  2. I spend more time trying to get all my packages installed, f-ing around with package.json .. installing , uninstalling .. then ACTUALLY CODING. I am betting the rest of the field is experiencing the same thing. Its like playing Jenga. One node upgrade of x.x.1 could break your application.

    Take Firebase .. going from 4.8.x to 4.10 requires different version of Angular 5 vs 6. HOLY SHIT! This is a major change… and you don’t know unless you read every single release doc in between. WHO HAS TIME FOR THAT?

    I am not going to do this … but it leaves room for a company like Microsoft or Telerik to offer a “premium” NPM service. I would GLADY pay $99/year for an NPM style repo that is more stable.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s