- Does the library have good documentation?
- A well-documented library is a sure sign that someone would like you to use their work. Moreover, if you can easily figure out what you need to do, then the whole purpose of the library is solved.
- Does the library have a license and is it compatible with your requirements?
Most libraries on NPM are MIT licensed and this is a very straightforward one. It allows you to use the software for just
about anything as long as you include the copyright license notice along with the source.
This is a really important item that cannot be stressed enough - a case in point was the licensing fiasco of Facebook's React library which initially did not come with a patent grant . Check out tldrlegal if you need help with other licenses.
- Is the library popular and widely used?
One would assume that if the answer to the above question is yes, then this is a good choice. In reality, it depends. Determining
the quality of a library is a very tricky prospect. Just because a library is popular and has a lot of Github stars,
it does not mean that lesser known option should be avoided, especially if it fits your needs better.
That being said, however, a popular library has a much higher chance that it will be maintained into the future if a lot of projects are dependent upon it. I am also personally a little wary of libraries sponsored by organizations - they automatically get a lot of advertisement and can really be a hit or a miss.
The following points focus in on the quality aspect of a library.
- Does the library have any security vulnerabilities?
You can use snyk.io to check for security issues. However, note
that npm version
>=6.3.0also provides an
audit fixcommand which can be used to check for and fix certain types of vulnerabilities.
- Does the library have tests?
- A sure sign of a good quality library is the existence of a suite of tests.
- Does the library have a lot of open issues and PRs?
A once popular library on it's way out will have a lot of accumulated issues and open PRs languishing without feedback. It
is usually a bit of an effort to scour through the repo but usually worth it for niche dependencies.
Moreover, it is important to note that code does not rust. Just because a library hasn't been updated in the past year, it does not automatically make it poor. It is quite possible that this is simply an excellent tool with a fixed scope that does it's job.
- Is the code well structured and can you understand it?
- I will readily admit that I have used more that one library that I don't (and probably never will) comprehend. However, if you can actually understand the code, it is a big plus as you could potentially even contribute back to the ecosystem. This is a big plus for me personally.
- How many dependencies does the library pull in?
- If you're looking to develop applications for the web where the bundle size is an issue, then this can be quite pertinent. In general, less is better.
The obligatory disclaimer:
Sometimes, I don't get enough time to go through all the items on this list myself. In this case, the first two points are just about enough for me to make a quick decision, i.e. check the documentation to see if this makes sense and then check the license before adding it in :)
Thanks for reading and happy dependency hunting!