You've started a fresh new project and have identified the app splits into multiple logical components. Instead of implementing them all by yourself, you've decided to look for existing solutions. It's been your lucky day, and you've found two packages with similar functionality, but you're not sure which one to pick.
"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 first to take a pulse on what the community thinks of the candidates. After a high altitude view has been done, you can review the project source repository for a more thorough assessment.
In this part, we will cover how to check on what others say about a package briefly. At this stage, we want to stay at a higher altitude and not spend too much time on the evaluation. We want to leverage on the legwork already done by others. We will 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.
Dependent projects
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.
Stars
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 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 many stars.
Npm also has its own star rating system, but it is not much advertised on the npm site.
Curated lists
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 exist lists of general modules that are useful regardless of the 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.
Health ranking
Similar to how StaticGen ranked the listed packages based on attributes, there are also general package health evaluating tools.
Package Quality calculates health indicator for an individual package.
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 a valuable choice for you, but it does not have a credible amount of Github stars. The package might not be included in any curated list. 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 the project's source repository. It is more thorough and time-consuming, but hopefully, this first phase has ruled out a few packages and left you with just a few to review more deeply.
Node doesn't wait for your database call to finish?
Learn how asynchronous calls work and make your app run as you intended. Get short email course on asynchronicity and two chapters from Finish Your Node App.
