Making Informed Decisions on 3rd Party Libraries

There are jokes and memes about how many node modules you have to use for a hello world React app. Using tools is hilarious 🙄.

For better or worse, node modules can get out of hand. I’m all for using them, but I do think it makes sense to consider the decision and thinking about the library you plan to use for a specific purpose. You are, after all, responsible for the code you ship, regardless of the source.

Decide if you actually need something

Depending on what you’re trying to do, it might make sense to build it yourself. I can’t tell you how many times I’ve seen a library installed to fill the need for

You might already have the dependency you need. If one of your dependencies has a sub-dependency on a package you already need, you might consider just upgrading it to a top-level dependency and using it.

Identify multiple options.

If you don’t already have an existing dependency that fits the bill, it’s time to round up a handful of options. You probably shouldn’t just run npm i on the first library that comes up in your google search.

For each candidate library, ask the following:

How does it measure up on bundlephobia?

Focus on the minified size (the gzipped size helps with network latency, but the big performance concerns are in the amount of code that needs to be parsed, evaluated and executed in the browser).

Is this a reasonable size to add to your project?

How do the alternatives compare in terms of bundle size and the ability to tree-shake?

How hard will it be to remove from your project?

Is it too much library for your needs?

Do we need everything it offers, or would we be better off with a subset of the functionality.

When you considered alternatives, did you focus on libraries that only offer the subset of functionality required, or do you need to reevaluate what you’re calling an alternative?

Does this need to be a library at all? Does the language, build process and/or framework currently being used support this out of the box? For example:

Do you need a library to enforce immutability in JavaScript, or can you just rely on language features to accomplish the same goals?

Do you need Redux, or can you just use React’s built-in state management capabilities? (hint: you don’t need Redux)

Would it be better to use the project as a starting point/reference to just build the functionality?

Be very careful you don’t slip into the NIH (not invented here) trap on this. Just because we can build something in-house, doesn’t always mean we should.

How healthy is the project?

If you’re counting on this library to stay up to date with changes in the ecosystem, have security patches applied, and have bugs addressed, you should try to get a sense of the health of the project.

These questions are things to consider, but don’t necessarily always mean the same thing or carry the same weight. For example: If a library hasn’t had a commit in a long time, but also has no open issues, and it is a dependency in a lot of active projects, it could just be “done”.

If it hasn’t had a commit in a long time, has a bunch of open issues that aren’t being addressed and isn’t a dependency of other projects, it’s probably not something you want to rely on.

Keeping the fuzzy nature of what these answers mean in mind, ask the following questions about the library:

How many open issues does the project have? How many issues have been closed? How long have open issues been sitting open? Do they have any conversation around them from the maintainers? When was the last commit? How frequent are the commits? How many contributors are there? Looking at npm, is this project a dependency of other successful projects?

How comfortable are you with the source code?

Look at the source code. Are you happy with how it is written and willing to accept ownership for that code if it breaks and it isn’t being addressed by the maintainers?

If it’s shipping as part of your project, you should be willing to make the changes you need to make on your own and contribute back to the project if they’re interested in your changes. If not, you may end up needing to maintain your own fork of the project. Don’t wait until you’re in a bind to find out you can’t work with the code you’ve decided to depend on.