You are building a fresh new project. You have split the program into logical components. You have picked one logical part and instead of implementing it yourself you have searched for existing solutions. It has been your lucky day and you have found two candidates that would suit your needs perfectly. But, you are a bit unsure which one to choose.
"How to decide between two packages with equal functionality?"
Top down approach - check community first
The evaluation process can be complex and time consuming. One good way is to first take a pulse on what the community thinks of the candidates. After a high altitude view has been done, a more thorough assessment can be performed by reviewing the project source repository.
In this part, we will cover how to briefly check on what others say about a package. At this stage, we want to stay at a higher altitude and not spend too much resources on the evaluation. We want to leverage on the legwork already done by others. We will roll up our sleeves and cover how to review the source repository in the next part.
We will be using a running example of choosing a package for coloring terminal output.
For coloring terminal output, there seems to be two dominant candidates. One is chalk package and the other is colors. We will be evaluating these packages.
The most straightforward measure of package reliability is to check how many other projects depend on it. The list of most dependent npm packages reveals many familiar packages. The number of dependent projects for an arbitrary package is not visible on the npm repository page, instead an alternate package aggregator such as libraries.io can be used.
Dependents on chalk and colors. Chalk has more dependents.
The rare case that a package was once popular but has been declining lately is a possibility. The number of package downloads in the last month is another metric that can be used for more timely assessment. Download statistics for a package are present on the npm repository page.
Downloads for chalk and colors. Chalk has more downloads.
Another simple indicator is the number of stars the project has on Github. Starring a project in Github is a way to express interest and approval for the project. It can be counted as social proof when when evaluating packages.
If the project is new it might not have many stars yet. It is possible that the project is gaining popularity fast. In this case it might be featured on the Github trending repositories listing.
Github stars for chalk and colors. Chalk has twice as much stars.
Npm has also its own star rating system, but it is not much advertised on the npm site.
There exists curated lists for specific topic areas. For example StaticGen lists top open-source static site generators. They are ranked based on attributes the site authors see important.
There also exists lists of general modules that are useful regardless of problem area.
Awesome Node.js is a curated list of delightful Node.js packages and resources.
Comparing rankings or presence in such sites can help decide over your candidates.
Chalk is part of awesome list, but colors is not.
Similar to how StaticGen ranked the listed packages based on attributes, there are also general package health evaluating tools.
Node Zoo searches packages and orders them in terms of reliability and community support
Chalk gets higher score than colors from packagequality.com.
Nodezoo.com gives colors and chalk the same rating
Package popularity only part of the picture
From our community analysis, chalk seems to be preferred over colors.
While all of these indicators are useful, they alone are not enough to see the whole picture. A package that is young might be valuable choice for you but it does not have a credible amount of Github stars. The package might not be included in any curated lists. Therefore, it is best to combine the analysis of social proof with your personal analysis.
In the next part, you will learn what to look at when reviewing project's source repository. It is more thorough and time consuming, but hopefully this first phase has ranked out few packages and left you with just few to review more deeply.
Semantic Versioning Cheatsheet
Learn the difference between caret (^) and tilde (~) in package.json.