How to pick the right dependencies for your Angular application?
Choosing the right libraries/dependencies for your Angular applications can make or break your project in the long run. I’ve seen way too many consulting clients stuck with an older version of Angular because of a dependency that isn’t maintained anymore.
Here are a few rules to follow:
1. Are you sure you need a dependency for this?
Do you really need one library for your date picker, one for your multi-select dropdowns, and one for your dialogs? The more dependencies you use, the more likely you are to get stuck at some point.
HTML/CSS is always evolving and supports dialogs/modals (my tutorial here) natively, as well as progress bars, sliders, color pickers, date pickers, and more… Such features are available at no cost since the code to run them is already in every single browser.
2. Trust well-known component libraries
If you do need several advanced components, use one single library that has them all. I always recommend Angular Material as the first choice because the library is maintained and released at the same pace as Angular itself, which means you can upgrade your apps with no delay when a new version of Angular comes out.
Kendo UI is pretty good, too, as is Project Clarity. You can recognize component libraries deeply involved in the Angular community because they always sponsor major Angular conferences. They invest lots of energy and resources in being performant and up-to-date because their library is their main source of revenue.
3. Is the library Angular-friendly?
The Angular team recommends libraries to use ngx- as a prefix to their name. Most libraries prefixed with something like ng2- or ng- do not follow that simple recommendation and, as a result, are most likely to cause issues in the long run.
While there are no warranties that maintainers of ngx- libraries won’t give up on their project at some point, I’ve found over the years that the naming alone is a great indicator that the maintainer(s) adhere closely to best practices and recommendations established by the Angular core team.
If the library is not Angular-specific, ensure it has Typescript type definitions available and doesn’t depend on too many other libraries or frameworks (yes, I’ve seen Angular projects depend on code that required React or Vue as a dependency!).
Always remember that the more code you add to a project, the slower your application will be.
4. Do your due diligence on npmjs.com
All Angular libraries are available on NPM, and NPM gives a lot of information away. For instance, let’s say I’m wondering if I should use Prettier or not:
Right from Prettier’s NPM page, I can see that the last version was published 4 days ago (it’s actively updated) and that there are over 14,000 projects using it (I won’t be alone).
There are also close to 30 million downloads every week, and growing:
The examples on that NPM page, the basic documentation, the number of opened issues… All of these are indicators that can help you decide whether or not to trust a library.
5. Do your due diligence on Github
If NPM looks good, then I always look at Github:
- How many open issues are there?
- Are people actively responding to issues and handling them? How fast does that happen?
- What kind of information is in the README file?
In the screenshot above, we can see that even if there are 938 open issues, more than 5,000 have been closed. Even the issues posted just a few hours ago have already received at least one response/comment. This tells me that I’ll get help if I encounter an issue with the library.
Some other good things to look at are:
- How many people contribute to the library? (if it’s just one or two people, what happens when they stop maintaining it?)
- How often are new versions released? Every few days, months, or years?
- Is there continuous integration with automated testing in place?
As far as Prettier goes, with 625 contributors working on the library, there isn’t much to worry about.
Conclusion
The above are most of the rules I follow. If there are no red flags in any of the above checks, then the library can be trusted as a dependency.
Let me know if you see any other checks to add to the list or if you have a different process.
My name is Alain Chautard. I am a Google Developer Expert in Angular, as well as a consultant and trainer at Angular Training where I help web development teams learn and become comfortable with Angular.
If you need any help with web development, feel free to get in touch!
If you enjoyed this article, please clap for it or share it. Your help is always appreciated. You can also subscribe to my articles here, and subscribe to my Daily Angular Newsletter to receive useful daily tips.
