NPM's Chaos and Possible Solutions

Published: Updated:

By now there are probably more articles about the flaws of NPM and the NPM registry than articles about how Java will die soon, but I feel like there haven’t been many of them which suggest solutions or workarounds to these problems, so these are the aspects I want to try to focus on in this article.

The Problems

Most of the articles I read in the past months regarding NPM boil down to a handful of problems:

  1. Quantity over quality - there are way too many packages, a lot of them redundant or of low quality.
  2. Needlessly deep and big dependency trees - a single, simply package often comes with hundreds of transient dependencies.
  3. Handling of package ownership and removal - see the infamous “left-pad” and “event-stream” incidents.
  4. Lack of security (often caused by point 2 and 3).

3 and 4 are problems only the NPM team can fix, and honestly I don’t see any simple solution for them. So lets focus on 1 and 2, which can fixed by package authors and consumers.

How Authors can Help Fix the Problems

A quality library or tool is good at what it does, having a clean code base which is covered by tests and handles edge-cases, while also making sure to have as little dependencies as possible, and all of these dependencies having a being of quality as well.

Here are some questions to ask yourself before publishing a package:

  • Does the code of this package justify publishing it for re-use? An infamous example of this is “is-even” which is…inverting the result of the package “is-odd”. If the content of your package can be written within seconds by someone else instead of adding the package as a dependency, or the same functionality exists in the standard library or a popular utility library like lodash, you probably wont need this as its own package.
  • Does something like this already exists? is it worth it to publish this rather than making a pull request for an existing package? (I’ve been guilty of ignoring this too many times myself)
  • Are the dependencies of the package acceptable? Are all of them required? Are there any which have a large amount of dependencies themselves? are they trustworthy?
  • Are you willing to maintain this package? This one is a bit tricky; While you should try to commit to maintaining your package, the GitHub user dominictarr also wrote a response to this regarding the “event-stream” incident with good points, showing why this one is not always possible.

How Consumers of Packages can Avoid the Problems

It is always a good idea to stick to popular, well tested and reviewed packages if possible, but to me it seems like finding those is not quite that easy in the JavaScript ecosystem; Usually the best way is to either search for the problem through a search engine, or search StackOverflow or GitHub and other source code repository hosts directly. For Java there is the very neat Apache Commons project which is basically a collection of high quality libraries for a large number of purposes, which makes for a great hub when looking for a library for a given problem. Sadly nothing like this exists for JavaScript (yet), as far as I know.