Vendoring is the practice of copying a project’s third-party dependencies directly into the project’s own source tree, typically into a directory named vendor, rather than downloading them from a registry each time the software is built. The dependencies travel with the code, so building the project does not require reaching out to the network.
The Go modules reference documents this mechanism in detail. The go mod vendor command “constructs a directory named vendor in the main module’s root directory containing copies of all packages needed to build and test packages in the main module,” along with a vendor/modules.txt manifest recording which module versions were copied. Once that directory exists, “build commands like go build and go test load packages from the vendor directory instead of accessing the network or the local module cache.”
The trade-off is concrete. Vendoring enlarges the repository, since every dependency’s source now lives inside it, and updates require recopying. In return, the build becomes self-contained and reproducible: it does not depend on a registry being online, on a package not being removed, or on a version being silently changed. The exact code used to build is visible in the repository and under version control.
While Go gives the pattern a formal, tooling-supported form, the underlying idea is older and common across many ecosystems, where teams check in copies of their dependencies to gain independence from external package sources and to guarantee that what they ship is what they reviewed.