Picking NodeJS libraries
Not all hammers are equal
It came to me as a realisation when I was writing the code for this blog. As a developer you have your own
system for assessing new dependencies. Some people have very simple system, where they take the first library
that solves the problem. Others may instead choose to pick the one that meets several layers of criteria.
I believe this is probably something that comes with experience, but there isn’t a good one-size-fits-all
rulebook that describes how most projects should manage their dependencies.
Anyway, in the interests of keeping this post to the point I wanted to outline how I pick a dependency
for a NodeJS project.
Types (if you’re into that)
Generally speaking if the project isn’t a tiny single file app,
I tend to pick Typescript. I won’t get into the nitty gritty of why, but
it adds a requirement: The package must serve types OR have a up to date
@types/package on DefinitelyTyped.
At the moment, nearly all major libraries include their own types and notable exceptions like express have
very well maintained
@types/ library. But there are exceptions, and introducing a type-less library either
means you will need to maintain your own types (which can be very dangerous), or you can forgo types altogether
which means you will be including unknowable types into your code.
You may be reading this and thinking this is surely a reason not to use Typescript. It might be, depending on
your use case but there are very few occasions I have had to do either of the above, and I can usually find a
library that matches my other requirements.
Fairly obvious one, but check the licence. You might be in for a nasty surprise. I’m not going to pretend to know
enough to advise on licence specifics, so a good starting place is checking https://choosealicense.com/licenses/.
Some licences may cause trouble for you should you plan to make an application closed source, such as GPLv3
which requires source disclosure.
If a package has not seen an update in a year or two, that may be cause for concern. Obviously some libraries
fill a simple goal, and don’t need regular maintenance but those are few and far between. Chances are if you
are seeking to add a new dependency to your project, it’s not going to be a “simple” piece of code. You don’t
need to do a deep dive into the packages history, but it’s worthwhile just looking if the community is active
on creating releases, or even just on the main branch.
This one really is a pinch of salt thing. Plenty of good quality projects may have many open issues and few closed
issues, but it’s worth glancing at the content of these issues. Is there a trend where issues have stopped being
responded to, has the latest version of NodeJS rendered this broken? Is there any hope? I always recommend a skim
before committing to using it.
Finally, I always like to see how liberal developers have been in adding dependencies to their project. If the project
pulls in hundreds of dependencies, it might be worth just seeing if you want to afford the extra burden of installing
those. Technically speaking, a breakage in a dependencies dependency can render you in serious trouble. Though these
kinds of breakages are rare.
Nothing else fits
Sometimes, there might be nothing that ticks these boxes. You might be looking for a niche solution (XMPP components spring to mind),
that you would rather stand on the shoulders of giants than…well construct your own. Just be sure that the giant is
made out of something strong :).
So in summary, it’s really something I’ve started to do over the years as I’ve maintained more and more NodeJS projects
and this article is certainly not prescriptive about what you must do. This is purely my criteria for selectiong
a depencency, and what has worked out well for me over the years.
NPM had 211,000 users in 2016. I couldn’t find
any information on the number of packages, but probably a good ballpark figure is 500,000 packages. That’s a lot
of software, so picking the right ones to carry into your project is important, and nessacery for the safety of users
as well as your enjoyment of the process itself.