Choosing Package Dependencies
03/12/2024
Applications today are built upon well-tested, reusable packages. These packages solve the most common aspects of software development, such as logging, authentication, handling HTTP requests, serialization etc.
It is a regular task for a development team to decide which dependency to take on. New features will be built-up these dependencies. A new dependency is an additional responsibility for team: updating and replacing the package without breaking the features built on it. Updating non-breaking or patch releases is a straightforward task, however replacing a library or updating it with breaking changes can be extremely costly. I have come across teams stuck with no longer maintained libraries for years, before the team managed to completely get rid of it. Any security vulnerabilities during this period pose a risk. Therefore, the decision for picking the right library has a huge weight.
I very often observe teams deciding application dependencies based on the packages' popularity. I think this is a fraud way of picking libraries. In this post I summarize the questions that I prefer to ask when I have to introduce a new dependency in an application. I expand on my questions in the space of .NET, C# and NuGet packages. I know some of the languages are vastly different to the NuGet package ecosystem, for example npm is has more and tiny packages. Developers of such ecosystems might take my concerns with a grain of salt and apply that best works for them.