Avoid reinventing the wheel is a good practice when developing any Software project. The focus should be on adding value to the end-user and not to re-implement that function to sort an array every time.
Thanks to open-source, there is a huge ecosystem of available libraries, that can solve most of the common problems you might have.
It can be very tempting for every task, to just look for an existing library that can do it for you and add it as a dependency to your project. Don't reinvent the wheel right? Well, yes, but every extra dependency comes with a cost and it is not something that should be done lightly.
When adding a third-party dependency, your project is now using code that you don't own.
What happens if that code has a bug or a security issue? Will it be fixed fast enough? And updates? Are they backward compatible or will break your application every time? Considering you will get any updates at all. The developer might just stop working on the project. Do you understand exactly what that dependency does and how to use it?
These are all important questions that you have to ask, but even before that, it´s important to understand if you really need it to use an external dependency for the functionality you are trying to implement.
May be is something you can write in a few lines of code? Or maybe you just need one function of a more complex library. In that case, couldn´t you just copy-paste it to your project without having to add the whole thing?
Taking the extreme example of NPM packages like is-odd or is-even. It´s one line of code of basic math!
Node community is known for abusing the usage of third party dependencies. You might have heard about the left-pad incident, where a function of a couple of lines broke half of the internet!
So, think well before adding an external dependency.
If you are decided that you really need to rely on an external dependency, it´s very common to find different implementations that solve the same problem. How to choose between them?
I will enumerate some factors that I consider important in the next sections.
Popularity
If a library is used by many people and has a big community around it, in general, it can be a good indicator of its quality.
A common used metric for popularity is the number of GitHub stars.
But be careful with this. Don't simply consider it as your unique decision factor. A library that was built by a big company or by a well-known developer, can have many more stars (because of more publicity for example), than a one done by a single developer or a smaller org. Or maybe it´s a library that exists at more time.
This criterion alone doesn't guarantee that is a better choice.
It´s a good indicator yes, but should be considered together with the other factors that I will talk about next.
Activity in the Repository
You don't want to depend on something that it´s not actively maintained anymore.
The frequency of commits, number of open issues and PRs and the speed that the PRs are merged are important indicators of project health.
Low activity in the repository can be a signal of worry but it depends on the use case. There are libraries that are so simple, that they don't really need changes every day or month. They just work.
Still, In most cases, I would avoid using a library that have very few commits in the last couple of months and/or with many open Issues / unmerged PRs.
Project maturity and versioning strategy
It´s best to depend on something that is stable and has a well-defined release schedule and versioning strategy.
Projects in the early stages of development might have breaking changes more often and can be riskier to use. The same with projects who don't have a defined versioning strategy like Semantic Versioning.
With SemVer you can have a better understanding of what´s have changed from one version to another and if it´s a bug fix or new feature, so you can plan ahead when to update your library version.
Who is the maintainer/core contributors
Another important factor to consider is who is the maintainer(s) of the project. Is it a known developer or a big organization? or just a single developer working in its free time?
In general, I would say that a project that is behind a big company or with a big number of contributors, can be a safer bet in terms of future maintainability and support, but again, it´s just an indicator, not rocket science.
This fact was indeed often mentioned when favoring React against Vue.js. React is a Facebook project, unlike Vue, where most of the code was done by a single man.
Still, the fact is that Vue has matured a lot and it´s one of the most popular JS frameworks right now, even surpassed React in terms of GitHub stars.
An opposite example is Polymer Project. A framework created by a big company like Google that never gained any traction.
Quality of Documentation
If you want to use a particular library, you have to understand how it works.
A library with poor or no documentation, it´s a big red flag for me.
At very minimum, it should have a README file explaining how to install and with code examples for the main use cases.
Test coverage
If a library has very few or no tests, how can you be sure that it will do what you are expecting it to do and that you won´t encounter critical bugs when integrating it into your project?
It´s really bad to have a bug on your application because of a bug on a third-party library.
Good test coverage can also show that the developer cares about the quality and maintainability of the software and that it's not just some experimental side project and can be used in production.
Number of dependencies
You are adding a dependency to your project, but that dependency will probably have their own dependencies.
This is something that many developers don't pay enough attention to. What are those dependencies? Are those still maintainable and trustworthy? Of course, it will hard to check every dependency but if a library has too many dependencies can be a warning sign.
In case of doubt, I will always choose the one with fewer dependencies.
Conclusion
Avoid reinventing the wheel is essential and thanks to all the amazing Open Source projects out there, our lives as developers are a lot easier as most of the common problems were already solved by someone else.
But adding a third-party dependency to a project is a decision that should be well thought, You project now depends on code you don't own or write. What if it has bugs? Will it be fixed soon enough? Will updates break your code? What if the developer just stops working on the library?
You can mitigate these issues by being rigorous when choosing the dependencies that you will add to your project. Give preference to the ones that are actively developed, have great documentation and test coverage and few extra dependencies.
A good strategy to minimize the dependency on a library in a project is to create a wrapper around it. This will make it easier to change as your application code will never call the library directly, but the wrapper. If you want to replace that library with another, just change the wrapper to use the new library internally and it´s done.
Another important thing is to keep your dependencies up to date. Tools like Dependabot or Renovate can give a big help with that.
What about you? Do you have any criteria for choosing a library that I didn't mention? Feel free to comment below.
Thanks for reading.
Latest comments (0)