This article was first published on the public account “Xiao Li’s Front-end cabin”, welcome to follow ~

Every developer has used NPM Install to install dependencies. Up to now, more than 190W packages have been hosted on the NPM platform. Facing the vast number of packages, what should we pay attention to when choosing third-party NPM packages?

Here are five best practices.

1. Check open Source licenses.

An open source license is a legal license. Through it, the copyright owner explicitly allows users to use, modify and share copyrighted software free of charge.

Copyright law by default forbids sharing, meaning that software without a license retains copyright, and even though it is open source, users can only look at the source code, not use it, which would violate copyright. So to open source software, users must be explicitly granted an open source license.

You can view the License of the NPM package at www.npmjs.com

Licenses are usually classified as “CopyLeft “and “Permissive” :

  • Copy-left: If you use this package, your code must also be open source. This is not friendly to commercial projects, such as the GPL and LGPL protocols.

  • Permissive: These licenses impose minimal restrictions on the use of packages and allow closed source. However, there are some differences between these licenses as shown in the following figure.

We can use the license-Checker tool to check that all NPM packages in a project are compliant at once.

2. Look at contribution frequency and downloads

The NPM platform has a weekly download and trend chart for the package, and a higher number means more people are using it.

Because there are many similar packages available in the community, such as moment.js and dayjs time and date libraries. NPM Trends can be used to compare download growth trends for multiple packages at the same time to get a more intuitive view of their popularity.

In addition, GitHub’s storehouse of stars, Forks, Commit Frequency, and Ficolin-related Stats can provide a profile of its popularity.

3. Weigh package volume

For the front end, the most direct way to optimize performance is to reduce the code package size. So when choosing a third-party package, you should also consider its package size.

Bundlephobia does a visual analysis of package size, and as you can see from the image below, moment. Js would be nearly 300 kB packaged and Gzip 70kB compressed.

Dayjs, on the other hand, is only 6 kB when packaged, which is much smaller than moment.js.

Lightweight DayJS is a better choice for projects with clear limits on the size of code packages like wechat Mini programs.

4. Check whether a large team is performing maintenance

Although most NPM packages contain full documentation, they tend to have compatibility, JS exceptions, or performance-related issues. So if there’s a big team behind the maintenance, we’re more comfortable with it.

We can pay attention to the following aspects:

Used By and ficolin-3

More means you’re not an early adopter, and many developers have already waded through the water for you.

Contributors view

You can see how often contributors are contributing, and if many of them are contributing frequently, that means the repository is receiving more attention and support from the community.

Community Standards

Compare the repository to the normative standards of the open source community. The more standards that are met, the more mature the repository is.

5. Assess security

Package Security is another key factor in choosing an NPM package, and you can see its Security policy under the Security TAB in your repository.

Active is displayed if the maintainer has taken steps to ensure security.

For existing NPM dependencies in your project, you can use the command NPM audit to perform security checks.

Npmgraph is able to perform dependency visualization analysis on packages to ensure there are no security vulnerabilities before installing them into projects.

conclusion

Review the five best practices for selecting third-party NPM packages:

  • Checking open Source Licenses
  • Look at contribution frequency and downloads
  • Weigh package volume size
  • Is there a large development team doing maintenance
  • Assess safety

When making a choice, we’d better produce a research document based on the above dimensions, share and discuss within the team, and finally reach a unanimous conclusion.

reference

  • Blog. Bitsrc. IO / 5 – best – prac…

  • Blog.51cto.com/u_13859849/…

  • www.ruanyifeng.com/blog/2011/0…

  • www.runoob.com/w3cnote/ope…

Thanks for your support ❤️

If this article has been helpful to you, please give me a like.

My public account “Xiao Li’s front-end cabin” has just been created, and is still improving. Pay attention to me and become stronger together! 🚀