"You're working on an application. Let's call it "FooApp". FooApp has a dependency on an open source library, let's call it "LibBar". You find a bug in LibBar that affects FooApp. To envisage the best possible version of this scenario, let's say you actively like LibBar, both technically and socially. You've contributed to it in the past. But this bug is causing production issues in FooApp today, and LibBar's release schedule is quarterly."
"There are a few common reactions to this type of scenario, all of which are bad options. I will enumerate them specifically here, because I suspect that some of them may resonate with many readers: Find an alternative to LibBar, and switch to it.This is a bad idea because a transition to a core infrastructure component could be extremely expensive."
"Vendor LibBar into your codebase and fix your vendored version.This is a bad idea because carrying this one fix now requires you to maintain all the tooling associated with a monorepo: you have to be able to start pulling in new versions from LibBar regularly, reconcile your changes even though you now have a separate version history on your imported version, and so on."
FooApp depends on LibBar, and a LibBar bug is causing production issues. LibBar's quarterly release schedule makes waiting for an upstream fix unacceptable. Switching to an alternative library is costly due to heavy transition overhead for core infrastructure. Vendoring LibBar forces ongoing maintenance of import tooling, reconciliation of separate version histories, and continuous merging of upstream updates. Monkey-patching LibBar creates tight coupling to a specific version, violates compatibility contracts, and requires replicating upstream test suites to maintain confidence. Implementing local workarounds also carries hidden costs and complexity. Each common reaction introduces significant long-term maintenance and testing burdens.
Read at Glyph
Unable to calculate read time
Collection
[
|
...
]