Do you check before installing 3rd party libraries?Last updated by Tiago Araújo [SSW] about 1 year ago.See history
Efficient software developers don't reinvent the wheel and know the right libraries to use. Using an existing and well-tested library will speed up development time.
However, there are scenarios where the libraries integrated in a project bring overhead in the future. For example, if a project is using a NuGet package that is no longer being maintained and does not support the latest .NET version. This incompatibility would force the development team to refactor the code to use another library if they wish to use the latest version of .NET.
Looking for the right library can help to minimize the chances of a project hitting these scenarios. Here are some of the common things to check before installing a library:
Only install libraries that bring big value to the project.
❌ Libraries for trivial functions (e.g.
is-odd - checking if a number is odd or not)
✅ One library for one use-case e.g. one for component, one for authentication
✅ Libraries providing complex or standard use cases that have been tested thoroughly e.g. validating credit card numbers, validating email format
The next thing to consider is the library’s lifespan. The last thing that we want is to integrate a library into our project only to find out that next month it will no longer be supported.
Couple of things to check:
✅ High download count – Frequently used libraries are more likely to be supported longer.
✅ Recently updated – Checking the library’s last updated date is a good start to decide whether the library is actively maintained or not.
✅ Good maintainers profile – Libraries sponsored by big companies (e.g. Angular by Google) or established names would be more likely to last longer than a library maintained by an unknown person.
✅ Low GitHub issues count – Many unresolved serious issues may be an indicator that the library is not actively maintained.
Most libraries are only built for a specific version of a runtime / framework.
e.g. The npm library
@firstname.lastname@example.org is only targeted for Angular 14 and NuGet library
v6.0.7 only supports .NET 6.
It is important to check the compatibility to make sure that the library will work as intended.
Although some libraries can work with older framework versions, it’s a good idea to avoid being in this situation as this could introduce unintended bugs which increase the overhead in debugging your code.
Next is to dive deep down into the details and check for the quality of the library itself.
Here are things to check:
✅ Maintainer's profile - A high profile maintainer with a good presence in the community or who is doing a lot of contribution provides a good boost of confidence in the library.
✅ Presence of unit tests and good coverages - This improves our confidence that the code will not break across versions
✅ Changelogs and versioning - Good changelogs between releases enable developers to check for any potential breaking changes.
Always check the license associated with the package before deciding to use it in production. You can check common available licenses on choosealicense.com.
Client-side applications (Angular, React, or Blazor WASM) benefit hugely from reducing the size of the code that a user needs to download (also known as bundles) to run our application.
Installing and using many libraries can increase the size of our application's bundle and slow down these client-side applications. Staying aware of the bundle characteristics and optimising the size where possible can ensure that we keep our application start-up quick.
On top of this, we can also check for a library’s tree-shaking capability. Tree-shaking is a process to remove unused code from a library in the final bundle.
Unfortunately, there's no easy way to know if a library is tree-shakable other than to read the documentation and experiment with tools such as BundleJs to see the final bundle size when importing several items from the library.
Unfortunately, there are no tools available yet to check for bundle size of NuGet packages.
- Document the decision - Always keep track of the reasoning when developers decided to go with a particular library instead of another one. This helps future developers working on a project to maintain the project. Future developers will have better context and will be able to make a better decision should there be any situational or business requirement changes. A package audit log is a great way to record all the decisions.