How to determine whether you should use an npm package or not

Luckily I’ve created a site that does this for you: https://www.shouldiusethispackage.com/

The Javascript world is filled with countless open source packages. Which is amazing, but is a double edged sword. Using the wrong package can create issues and cost significant amounts of time. I’ve written about the pain of upgrading dependencies before.

Many of you have likely used packages that ended up stale. The sole owner disappears and won’t merge any new pull requests. You end up having to fork the library and run off your own fixes. It ends up being more costly than helpful. So how do you pick a package that’s going to bring you more gain than pain?

Provides functionality that you can’t easily build yourself

The first question I ask when looking at a package is “Does this provide some functionality that I couldn’t easily write myself?” Often the answer is no. In this case, just build it yourself!

Why depend on somebody else for something that you could do simply? What happens when you encounter a bug? It’s easier to debug your own code rather than digging through somebody else’s library that you intended to use as a black box.

However, frequently the functionality provided is vast and takes in many considerations that would be costly to implement yourself. In this case, feel free to take the library into further consideration.

Community and contributor balance

The most important thing behind a package is the community! That’s what makes or breaks it at the end of the day. Look at a number of indicators here.

How many core contributors are there? If it’s just one or two, that is a weakness. What happens if the sole owner has personal issues and can no longer maintain or update the library. It’s doomed to become stale. The more core contributors, the better!

What about moderate contributors? People who appear to step up to the plate and contribute when necessary. Again, the more the better!

Who’s opening the pull requests for the repo? Are non-owners doing it? Are non-owner’s pull requests getting merged or just left sitting around or closed?

How many stars does this have? How many people have forked it? How many people are downloading it every month? The higher the numbers, the more likely it is that somebody be willing to jump on a bug or issue that arises.

Freshness and age of the package

Always look for historical evidence that this package has been maintained and will continue to be maintained in the future.

If it’s brand new, be skeptical. Who’s to say the creators won’t get bored after the initial rush? If it’s been around a while and contributions/releases seem consistent, that’s a good sign.

Always look at the last commit or update to the repo. Sometimes a previously well maintained library just dies. Not having been updated in a while is a good indicator of this. Think about it this way: if you open a pull request, will the owners be attentive and review/merge it, or will it sit around and become stale?

Another good indicator of this is to take a look at the currently open pull requests. How old are some of them? Is there much discussion in the comments? Who’s partaking in the discussion? The owners, or other people using the library?

Stability and responsiveness to issues

Take a look at the number of issues that exist. Read the comments. Does it look like they’re going to get fixed, or that people are interested in fixing them? Are the owners attentive to bugs or do they not seem to care?

Is the package being released often? If the bugs and issues do get fixed, can you expect to be able to take advantage of that soon? Or are you going to have to fork the repo and point to your fork?

Does the package have a good README or docs? Sure you can always read the source code, but it’s much easier and less time consuming to work with something that’s well documented. Docs also demonstrate that somebody working on the project cares about the people using it.

How many dependencies does this package have? Just like you’re doing, hopefully they have avoided taking on bad dependencies. The higher the number, the more fragile the package is likely to be. What libraries are they depending on? Existing stable projects or sketchy ones?

Conclusion

Pick your dependencies wisely! You can’t always predict what will survive and what will go out of style. But you can make an educated guess. Use my tool, https://www.shouldiusethispackage.com/, to help you. And don’t forget to contribute to open source projects while you’re at it!