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.
Most of the articles I read in the past months regarding NPM boil down to a handful of problems:
- Quantity over quality - there are way too many packages, a lot of them redundant or of low quality.
- Needlessly deep and big dependency trees - a single, simply package often comes with hundreds of transient dependencies.
- Handling of package ownership and removal - see the infamous “left-pad” and “event-stream” incidents.
- Lack of security (often caused by points 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.
A good, high 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 few dependencies as possible, and these dependencies having a certain 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 to an existing package? (I’ve been guilty of ignoring this a few times myself)
- Are the dependencies of my package acceptable? Are all of them required? Are there any which have a large amount of dependencies themselves? are they trustworthy?
- Am I 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.