5 ms·

vendoring is a bit of project smell, but for large teams it removes the confusion of who has what version of a dependency unfortunately most teams don't schedu

vendoring is a bit of project smell, but for large teams it removes the confusion of who has what version of a dependency unfortunately most teams don't schedule a periodic `go mod tidy` so you just end up with ancient deps most people never read the code of the deps they pull in, so I don't think vendoring provides any security assurances

icholy 3y ago
That's not what `go mod tidy` does ...
Paul-Craft 3y ago
I'd go way farther than "a bit of a project smell." I literally cannot think of a single instance in which vendoring a dependency for any reason other than, say, caching it for CI so you don't have to worry that the maintainer pulls a `left-pad` on you, has gone well. If the package has bugs, you're far better off either waiting for upstream fixes, working around the bug in your application code, or just switching to a different library. That goes double if the library you're using is missing a feature you need, even if it's scheduled for the next version release. Unless you're prepared to maintain a full-on fork of the dependency (and, if you do, please make it public), everything about vendoring for these reasons is 100% bad for you for very little incremental benefit. It's like the joke about regular expressions ("You have a problem and think 'I'll use regexes to solve it.' Now you have two problems"), except it's not a joke, and it sucks way more. TL;DR: Vendoring to cache for CI/build servers, yes. Any other reason, just don't; it's not worth the headaches.
- ownagefool 3y ago
  If you work on code that introduces threat to life, you might be prepared to own all the code, even if you don't write it all from scratch.
dilyevsky 3y ago
> it removes the confusion of who has what version of a dependency go.mod/sum files already remove that confusion as it’s their intended purpose

5 ms·

vendoring is a bit of project smell, but for large teams it removes the confusion of who has what version of a dependency unfortunately most teams don't schedu

by 0zemp2c 3y ago

icholy 3y ago
That's not what `go mod tidy` does ...
Paul-Craft 3y ago
I'd go way farther than "a bit of a project smell." I literally cannot think of a single instance in which vendoring a dependency for any reason other than, say, caching it for CI so you don't have to worry that the maintainer pulls a `left-pad` on you, has gone well. If the package has bugs, you're far better off either waiting for upstream fixes, working around the bug in your application code, or just switching to a different library. That goes double if the library you're using is missing a feature you need, even if it's scheduled for the next version release. Unless you're prepared to maintain a full-on fork of the dependency (and, if you do, please make it public), everything about vendoring for these reasons is 100% bad for you for very little incremental benefit. It's like the joke about regular expressions ("You have a problem and think 'I'll use regexes to solve it.' Now you have two problems"), except it's not a joke, and it sucks way more. TL;DR: Vendoring to cache for CI/build servers, yes. Any other reason, just don't; it's not worth the headaches.
- ownagefool 3y ago
  If you work on code that introduces threat to life, you might be prepared to own all the code, even if you don't write it all from scratch.
dilyevsky 3y ago
> it removes the confusion of who has what version of a dependency go.mod/sum files already remove that confusion as it’s their intended purpose