[0zemp2c]

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

[dilyevsky]

> 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

[icholy]

That's not what `go mod tidy` does ...

[Paul-Craft]

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]

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.