What does `go mod vendor` create, and how does it change what `go build` uses?

## The problem vendoring solves By default a Go build resolves imports through the module system: `go.mod` names the modules and versions the build needs, and the `go` command finds that source in the local module cache, downloading it if it is not there. That works well when the machine doing the build can reach wherever those modules come from. It works badly when it cannot — a release build on an isolated machine, a build environment with no outbound access, or a rebuild of an old commit long after the fact. Vendoring answers that by putting the dependency source **inside the repository**. The command is: ``` go mod vendor ``` ## What it copies It does not copy modules wholesale. It starts from the packages of the main module — every package the module builds, plus everything their tests import — and follows imports transitively. Only the packages actually reached are copied. A dependency repository containing forty packages of which you import one contributes one package directory. The dependencies' own `_test.go` files, their `testdata`, their documentation and their version-control metadata are not copied either. This is why a vendored tree is usually far smaller than the sum of the modules it was built from. The result is a directory tree at the repository root, laid out by import path: ``` vendor/ modules.txt golang.org/ x/ text/ unicode/ norm/ ``` ## The index file Copied source files carry no record of which module or which version they came from — a `.go` file under `vendor/` looks exactly like any other `.go` file. So `go mod vendor` also writes `vendor/modules.txt`, which records, for each module: its module path and selected version, an annotation marking whether the main module requires it directly, and one line per package copied. That file is the only place the versions live once the tree is on disk, and the `go` command reads it rather than trying to infer anything from the files. ## How the build changes The key behaviour, and the part that surprises people, is that **nothing has to be configured**. Since Go 1.14, if a `vendor` directory is present at the module root and `go.mod` declares `go 1.14` or higher, the `go` command behaves as if `-mod=vendor` had been passed. Imports resolve out of `vendor/`; the module cache and the network are not consulted at all. An import that is not present under `vendor/` is an error rather than something to go and fetch. That means checking a `vendor` directory into a repository silently changes how every developer's `go build` resolves packages. It is a decision with consequences, not a local convenience. ## It is regenerated, never patched `go mod vendor` resets the directory: it removes what is there and writes it again from the modules `go.mod` selects. Two consequences follow. First, nothing updates `vendor/` for you. If you add an import of a new dependency, or change a version in `go.mod`, the vendored tree is now stale and you must re-run the command and commit the result. The build will tell you, loudly, that the two disagree. Second, any hand-edit you make under `vendor/` is temporary. It compiles — the `go` command has no idea it was not the original — and then vanishes the next time anyone regenerates. Patching a dependency by editing vendored source is therefore a change that works on your machine and disappears without warning. ## Practical notes - `go mod vendor -v` prints the modules and packages it copies to standard error, which is a quick way to see what actually came in. - The command does not modify `go.mod`; it only reads the module requirements and copies source accordingly. - Because vendored files are compiled exactly as they sit on disk, and are not re-checked against any recorded module hash during a build, the committed tree is the artifact's real input. Whatever is in the commit is what ships. ## The short version `go mod vendor` turns your dependency graph into files in your repository, plus an index describing them; and once those files exist, the `go` command quietly builds from them instead of from anything it would otherwise download.