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.
Most of the articles I read in the past months regarding NPM boil down to a handful of problems:
- 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?)
- Needlessly large dependency trees - a single, simple package often comes with a ton of transient dependencies.
- Handling of package ownership and removal - see the infamous “left-pad” and “event-stream” incidents.
- 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.
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.