The last time we were discussing this was in #2266 - please have a read of that PR description as it provides some context.

Go doesn't have widely used gem and rubygems.org equivalent yet. Instead, several third-party tools are used, which fetch dependencies from Github and other places, and lock versions to particular commit hashes.

Now we have the official Go Modules.

If vendor/ is not included in the repository, then go get will download sources – but it will be the latest commit for each import path (more or less is equivalent of repository URL), not specified commits from lock file.

When people use Dep, Glide or any other third party Package Management Tools, they don't use go get. They usually use dep ensure or glide install and these third party package managers have lock file which prevents fetching the latest commits.

Thanks for the extra details @mmhyamin! That PR was from January 2017 and I figured a lot has changed since then.

I'd also love input on this proposed change from recent contributors to this template: @tchajed @mxschmitt @bndw @AlekSi

I would let the user choose if they want to include the vendor directory into her repository. There is not a single correct answer and it depends often on the project or use case itself. Maybe we can add it but comment it, so that the user can remove the comment if he wants and ignore the vendor directory.

Note: afaik, go modules can and should be used without the "go mod vendor" command. So that's optional -> not in every repo is a vendor directory.

Now we have the official Go Modules.

They are still experimental. Even after Go 1.13, it would be years until most of the community moves to them.

Note: afaik, go modules can and should be used without the "go mod vendor" command. So that's optional -> not in every repo is a vendor directory.

+1. I don't understand why you want to have vendor/ but ignore it.

From #2266:

Even people who disagree with this opinion would agree that omitting vendor/ should be opt-in, not opt-out.

I still think this way.

@mxschmitt I like the idea of commenting it out.

+1. I don't understand why you want to have vendor/ but ignore it.

We don't use go mod vendor for production. But during development, we use go mod vendor as some editors cannot resolve the dependency and show import error.

I spent considerable time trying to figure out what the vendor/ directory is for and my current understanding is there are two use cases:

• Use go mod vendor and commit the vendor/ directory. This puts the full source code for dependencies in the repo. It is also compatible with old versions of Go (Go 1.10 maybe?).
• What @mmhyamin is using them for (as I understand) is to run go mod vendor so that editor tools work, which support the vendor directory better than Go modules. However, the build generally uses Go modules to specify and fetch dependencies (for go mod vendor itself and in production).

In addition, there are a lot of legacy tools which used a vendor/ directory that I don't understand but that people might still be using.

Personally I feel like ignoring the vendor/ directory and using go mod vendor may very well solve my editor issues with Go modules. However, my confidence in my understanding of the overall ecosystem is low enough that I don't want to prescribe anything for the gitignore.

See https://golang.org/cmd/go/#hdr-Vendor_Directories and https://golang.org/s/go15vendor for vendor/ overview.

It is also compatible with old versions of Go (Go 1.10 maybe?).

vendor/ support is enabled by default since Go 1.6.

In addition, there are a lot of legacy tools which used a vendor/ directory that I don't understand but that people might still be using.

They are not legacy yet. First, support for Go modules in various static analysis and code generation tools is not trivial and quite painful ATM. Some tools support them already, most don't. Second, Go modules will be enabled by default only in Go 1.13 (to be released in August). Lastly, even after Go 1.13, many people will continue to use the vendor/ directory because they want to have all code in the repository and/or fully offline builds. The initial plan for Go modules included the deprecation of vendor/, but that was changed, and explicit better support for vendor/ was added (go mod vendor, go build -mod=vendor): https://github.com/golang/go/wiki/Modules#how-do-i-use-vendoring-with-modules-is-vendoring-going-away.

Personally I feel like ignoring the vendor/ directory and using go mod vendor may very well solve my editor issues with Go modules.

Then add vendor/ to .gitignore in your project. But given all the reasons above, I don't think that should be the default behavior for new GitHub Go repositories.

@mxschmitt changed it according to your suggestion.