What are the benefits of having a vendor folder? [closed]

Question

I can't really grasp the purpose of having a vendor folder. Based on what I learned, it seems the vendor folder is only beneficial if you're trying to make your repo compatible with golang versions earlier than 1.11. We are running golang 1.12.14.

When I brought this up to my coworker he said:

Please use vendor with modules - go doesn't have a global artifactory. this is, currently, the best option to make sure you have hermetic builds and your code doesn't break when somebody changes something in their repo.

I thought this is what Go modules does? I asked this question and a commenter is saying I shouldn't use vendor? Does it make sense to add `go mod vendor` to a pre-commit hook?

Inning

vendor was one way you could freeze dependencies before modules. Notice it's not mentioned at all in the documentation of How to Write Go Code – Jato

You coworker was right and is right but his conclusions are wrong nowadays. Modules allow reproducible builds with proxies. – Hannis

sometimes i do found very practical to have third party code in a separated (but related) folder called "vendor" on the root folder of my proyect. It was very easy to explore and modify code. Is like getting a component and fune tune it (i even fix some things). I guess having a vendor folder or not it is not something good or bad, it depends. Saying this, i have to say that a vendor folder IS beneficial in a broader sense than you state. – Utterance

If unsure, then don't use a vendor directory. Go will use GOMODCACHE automatically, which will speed up downloading, if you work on several Go projects. But be sure to commit go.mod and go.sum to git. – Pricilla

Answer 1

Go modules bring the guarantee that you will be able to build your packages deterministically by locking down the dependencies into a go.sum. That being said, the promise to deterministically build your project only stands if your dependencies are still accessible in the future. You don't know if this is going to be the case.

Vendoring on the other hand, with or without Go modules, brings stronger guarantees as it enables to commit the dependencies next to the code. Thus even if the remote repository is no longer accessible (deleted, renamed, etc), you will still be able to build your project.

Another alternative is to use Go modules along with a proxy. You can find more information in the official documentation. You can also look at some OSS implementations like gomods/athens or goproxy/goproxy. If you don't feel like setting up and maintaining your own proxy, some commercial offers are available on the market.

So should you go mod vendor each time you commit? Well it's ultimately up to you dependending on the kind of guarantees you want. But yes leveraging a proxy or vendoring your dependencies help getting closer to reproducable builds.

Karonkaross

On the other other hand, if a third-party dependency is taken down, that means it's no longer getting updates, and therefore should no longer be considered safe for use. – Sparling

That's a good point, but not all takedowns are intentional. Proxying/Vendoring also protects you from transient errors (e.g.: GitHub being down). – Karonkaross

The default Module proxy hosted by Google is also unavailable in some countries, and so including a vendor directory can also reduce issues for folks in those countries who aren't used to working with Go. – Allhallows

If you're in a country where it's inaccessible, you'd have it turned off, making it irrelevant to vendoring. – Sparling

So if I use go mod vendor and there are changes to the vendor directory. I still need to check if anything is broken after since go is going to use the dependencies indicated by the vendor folder over the ones dictated in go.mod? – Inning

Go (1.14) doesn't add any vendor info in the go.mod/sum. But it seems to exclusively look in the ./vendor directory if it exists. It also performs integrity checks to some extent. For example, rm -rf vendor && mkdir vendor && go run . would result in an go: inconsistent vendoring. Deleting a single package will also result in an error. Altering a package source doesn't result in an error. – Karonkaross

go mod vendor updates the vendor folder to the indications of the go.mod/sum files and the vendor folder is the ultimate source of truth for what package is being used? – Inning

Yes this is exactly this. – Karonkaross

Thank you for this. I am now using the vendor directory to use modules that are in private git repos in a dockerfile. Can't use them directly because auth is difficult/bad in the docker build context. – Roughneck

Answer 2

Note: with Go 1.17, go mod vendor (from 1.17 Go commands) might be easier to use:

vendor contents

If the main module specifies go 1.17 or higher, go mod vendor now annotates vendor/modules.txt with the go version indicated by each vendored module in its own go.mod file.
The annotated version is used when building the module's packages from vendored source code.

If the main module specifies go 1.17 or higher, go mod vendor now omits go.mod and go.sum files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree.

Jeavons

Answer 3

Vendor Folder is a great way to organize and manage third-party dependencies in your project. It is especially useful when your code relies on external libraries or frameworks.

Benefits of having a Vendor Folder:

• It helps to reduce dependencies conflicts.
• It allows you to keep a separate version of each library / framework installed in your project.
• It helps to keep the project structure clean and organized.
• It makes it easy to update, install, and remove any dependencies with minimal effort.
• It makes it easier to switch between different versions of a library or framework.

Efficient