With tens of thousands of package options available on the NPM registry sometimes it becomes difficult to decide on which package you should choose, choosing a bad package can result in hours of debugging and troubleshooting.

What is NPM?

npm is the world's largest software registry. Open-source developers from every continent use npm to share and borrow packages, and many organizations use npm to manage private development as well.

I am assuming that if you are reading this you are already using npm in one way or another, so I will skip going into details on npm :). If you are new to JS you can read more here.

Reason for this post

It is usually good to have certain guidelines you follow while selecting a package. Having a guideline can also streamline the process in the team where everyone just follows these guidelines so that no one in the team ends up adding a bad package that can affect the stability of the system.

1. Popularity/ Downloads and GitHub metrics

Once you go to the NPM details page for the package check the Weekly download, which tells you how many developers downloaded/ used the package in their project in a weekly timeline.

A larger count of downloads is usually a good indicator that the package is being actively used by the community.

Also, visit the GitHub repository for the package, usually, every NPM package is required to have a GitHub repository that is open for the developers to look at a good fork, watch and star count on the repository is also a good sign that a lot of people are involved in the development of the package.

2. Community/ Contributors/ Maintenance

Once on the package details page on the NPM website, check for the last published date and contributors count, it is the last time a newer version/ patch was released for the package.

A Recent date is a sign that the package is maintained actively still and in case there is any issue that you face with the package there is an active community that can help you resolve those issues.

A larger contributor count is usually an indicator that the package is not maintained by a single person. Not that a single-person package is a bad choice there are a bunch of packages that are developed by single developers and are maintained well, but a larger contributor count is usually a good indicator.

3. Peer Dependency

You will find that NPM packages are usually built by leveraging other NPM packages, these packages that are used to build the package you are checking are called Peer dependencies. Having peer dependencies have its Pros and Cons, we will not go into understanding these as it will take a while.

But usually, I like to avoid packages that have a lot of peer dependencies as it gives me an implicit idea that there are a lot of other packages the code is dependent on, and if ever any of these peer dependency packages have an issue/ security vulnerability it can affect the project I am working on.

But I would like to know your opinion on this also, what do you think about this?

4. Documentation

It's much better to go with a package that has well-defined/ written documentation, which means that the package is maintained well. Package developers/ maintainers usually maintain documentation as separate websites or on the GitHub repository some of the points you can check if a package has good documentation are:

1. Details on features that are available on that package.

2. Any documentation for API and methods that are exposed by the package.

3. Code examples for simpler integrations.

4. Steps to run the project in your personal environment. (if you need to run it).

5. Any Demos that you can try.

6. Any list of upcoming features.

5. Github Metrics, Open, and Closed issues

In the first point, I mentioned that metrics like fork, watch, and stars count on the packages GitHub repository are generally good indicators.

Along with these check for the Open and Closed issues on the repository, you can check them by going to the Issues tab on the repository.

• If the number of Open issues is less it's a good indicator

• while if the number of Closed issues is more it's usually a good indicator.

6. Package Size

Usually, if you are checking for a package for your client-side application, the size of a package will be important, as a larger size package can increase the size of your bundled JS delivered.

On the package details page on the NPM website, you can see the package size/ Unpackaged size value that you can take as a reference while comparing the size of the package

7. Security

Security is a big concern when you develop an application that uses external packages. Having a vulnerable package can result in data loss, unauthorized access to sensitive data, service outages, and other issues.

You can do a basic vulnerability check on the packages you are using by the audit utility provided by NPM. You can read more about it npm audit.

To know more in-depth about the right practices for checking npm packages security you can check this article OWASP cheatsheet series.

Conclusion

Just to also share not all packages will have all these points checked in, some will not have good documentation, and some may not have a large number of downloads. But while comparing as long as some or most of these are checked it is a good sign that you can go ahead and integrate that package into your project.

I would also like to know from you, what criteria you generally look for when you decide on integrating a package.

Please feel free to share your thoughts and comments in case you find this helpful, or if you disagree with any of the above points :).

Request from me

If you read the post now and if you found it helpful, I would request you to please share your thoughts, and opinions, which part you liked and which part you did not. This will help me write better posts in the future.

Thank you in advance, hope this was helpful.