As programmers, our death by dependency hell stems from our lack of knowledge of what our dependencies do, and our lack of hesitance adding dependencies. What should we do instead?
Please follow me into a brief journey of library development. You got this mad idea that might work. And it’s gonna be great! Should you share or not? If you share, you know some parts of your library are going to be rough. And once you’ve commited to an API, you shouldn’t break userspace. Or, in Rich Hickey’s words, “Breaking changes are broken. It is just a terrible idea. Don’t do it.” Not sharing can be equally bad. Your idea may perish! It gets no nourishment, no sun, no light. No love. If you do share, your library may grow into a tool used by millions! And you’ll be stuck as the responsible party for all the sharp edges.
This loose/loose choice is a false dichotomy. You have a third option: don’t allow scope creep. The seedling of an idea can grow, but it can happen separately from the library it consumes. As a library author, you can encourage your users to consider in-lining. As a library consumer, you can read that README, and not immediately add the dependency. Instead, grab a coffee. Consider the problem at hand. And instead of adding the dependency, consider in-lining some code.
As library authors, we can choose to write in-line friendly libraries:
We have a final option that I rarely see taken:
We can encourage our users to consider in-lining.
This option is especially great when we write a library to infuse an ecosystem with an idea, rather than to obtain a long-term commitment for maintaining other people’s code bases.
Dear library authors. When you don’t want to create and maintain a big thing, consider encouraging your users to inline your tool. Your users may learn, and they won’t demand updates and features from you.
Dear users, Consider in-lining! It’s a great learning experience. And you’ll understand your code as a whole, not just the parts you see because it’s in your source directory, and not hidden behind dependency coordinates.
postscript. I recently shared an idea for how to travel in time with Git, delivered as 50 lines of code. I almost didn’t publish, because there’s enough libraries, you know? But I figured that I valued the idea enough to share. And when I can encourage users to consider in-lining, I can sleep soundly.