Reading an article from a former colleague, Proliferation of Depencencies got me thinking about how we manage dependencies today. There are inherent risks to blindly taking on a dependency to solve a single point need.
The tendency toward adding a dependency rather than writing code seems to be accelerating, at least from my observations.
The recent snafu with npm is a good example of how dependencies can be a risk. When Azer Koçulu removed all his npm modules, thousands of applications were suddenly unable to build. A situation that never should have happened due to namespacing, curation, and thoughtful dependency taking, it was a wake-up call to the node community. Many projects were dependent on a single package ‘left-pad’ that was only a couple of lines of code.
Taking a dependency on someone else’s code that isn’t part of a core language framework, especially for 3-4 lines of code, is an unnecessary risk. Alternatives to consider are to write the code directly into your project, or fork the dependency you’re considering taking.
The broader consideration is around how to curate an ecosystem such as npm. Languages and code bases with a benevolent overlord such as the Linux kernel, Microsoft’s .NET CLR, or Google’s Go have the benefit of a tie-breaking entity to minimize dependency sprawl. OSS projects without a strong advisory and curation group have a higher risk of dependency sprawl.
While a Swiss Army knife solves problems, a Swiss army chainsaw can make a mess.