3 ms·
> Don’t vendor your dependencies. The alternative seems worse: your own application's stability is now at risk against upstream changes that could break your c
by otterley 2y ago
> Don’t vendor your dependencies.
The alternative seems worse: your own application's stability is now at risk against upstream changes that could break your code. Sure, you might not get a fix immediately, but I'd rather know I'm making a change because I need a fix than introducing instability and additional risk that I don't want to subject myself to. "If it ain't broke, don't fix it."
- teddyh 2y agoYou can choose to either live at the slightly-bleeding edge (as determined by “stable” releases, etc), or to live on the edge of end-of-life, as discussed here: <https://news.ycombinator.com/item?id=21785399 https://news.ycombinator.com/item?id=21785399> (And surely you should have tests to verify all your own functionality after upgrading a dependency?)
- otterley 2y agoThat "should" is load bearing. Unfortunately thorough automated testing isn't frequently done by application teams, and even fewer automated testing of dependencies is done by them. Most developers assume, for better or worse, that testing of dependencies is the responsibility of their respective authors.
- skybrian 2y agoI like Go's approach, which ensures that all upgrades happen when you choose to do some upgrades. (For apps, a lock file will do it too.)
- cpeterso 2y agoTaking dependency updating to the extreme, some Google projects adopt a "live at head" philosophy, where their projects depend on their dependencies' top-of-tree main commits, not a release branch: https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/abseil-cpp/FAQ.md#what-is-live-at-head-and-how-do-i-do-it https://chromium.googlesource.com/chromium/src/+/HEAD/third_...