Yes, we do vendor everything, in that we have a snapshot of all of our dependencies in our source control system. But we do it across the entire codebase, not per project. That is, we typically only ever have a single version of a library for the entire company (with a few exceptions). If a project needs to update to a later version, they basically update everyone using that library. For widely used packages, this can sometimes be a time consuming process, but we've found it to be preferable to the alternative of having version conflicts all over the place. This is generally true not just for Go, but all languages. So the idea of a project needing to pin to a very specific version of a dependency and never update doesn't really fly.

I'm going to guess you're a Rubyist. I had to look up what "vendor everything" referred to. There's a reasonably well referenced blog post by a Rubyist -- but only referenced by other Rubyists. I see that the Bundler tool looks for a 'vendor' subdirectory, so I'm going to guess that's how it became a part of the Ruby lexicon.

Anyway, just wanted to point out that it's possible you're using Ruby lingo and not general-purpose tech terms. I could be wrong, maybe I just missed the boat.

I think "bundle everything" might make sense to everybody, including Rubyists.

"Vendor everything" was my conclusion to solving dependencies as generally as possible, while trying to knit PostgreSQL modules (locally produced schema chunks) and extensions with a base of versioned Rails apps.