CODEWITHSUNDEEP
govendorgo-modulesgovendor
Daniel Kobe
Daniel Kobe

Reputation: 9825

What are the benefits of having a vendor folder?

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?

Upvotes: 33

Views: 40884

Answers (3)

sigmoid
sigmoid

Reputation: 33

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.

Upvotes: 1

VonC
VonC

Reputation: 1324737

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.

Upvotes: 9

aymericbeaumet
aymericbeaumet

Reputation: 7332

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.

Upvotes: 63

Related Questions