NPM's Chaos and Possible Solutions


Last 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 felt 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 a lot of packages, many of them abandoned or near-duplicates of each other (who needs over a hundred different packages for calculating levenshtein distance?)
  2. Needlessly large dependency trees - a single, simple package often comes with a ton 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). There have been several incidents of backdoors or other malicious code being inserted into NPM packages (see “event-stream” in the previous point).

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

How Authors Can Help Fix the Problems

What makes a ‘good’ package? I would argue: A library or tool that is good at what it does, having a clean codebase which is covered by tests and handles edge-cases, while also making sure to have as few dependencies as possible, and all of these dependencies being of a certain quality as well. Additionally, it should be actively maintained and for example security issues should be fixed in a timely manner.

Here are some questions you could ask yourself before publishing a new package:

  • Does the code of this package justify publishing it for re-use? If the content of your package is limited to a handful of lines you probably won’t 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 I would argue that you should try to commit to maintaining your package, this one is not always possible. GitHub-user dominictarr also summed this up nicely in a response to the “event-stream” incident.

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 when comparing it to the ecosystem of other languages, notably Java and Python; For Java there is the very neat Apache Commons project which is basically a collection of quality libraries for many 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.