Go > Packages and Modules > Go Modules > Managing dependencies (go get, go mod tidy)

Go Modules: Vendoring Dependencies

This example demonstrates how to use Go modules to vendor dependencies in a Go project. Vendoring copies the project's dependencies into a local vendor directory within the project, ensuring that the project can be built even if the original dependencies are unavailable.

Understanding Vendoring

Vendoring is the process of copying the project's dependencies into a local directory (usually named vendor) within the project. This allows the project to be built even if the original dependencies are unavailable (e.g., if a remote repository is down or has been removed).

Enabling Vendoring

The go mod vendor command copies all dependencies listed in the go.mod file into a vendor directory in the project root.

go mod vendor

Using Vendored Dependencies

After running go mod vendor, Go will automatically use the dependencies in the vendor directory. No code changes are necessary.

Commiting the Vendor Directory

It's common practice to commit the vendor directory to your version control system. This ensures that everyone working on the project uses the same versions of the dependencies, regardless of their network connectivity or the availability of the remote repositories.

Real-Life Use Case

Imagine you're working on a critical project that needs to be built and deployed reliably, even in environments with limited or no internet access. Vendoring ensures that the project can be built using the local copies of the dependencies, without relying on external sources.

Best Practices

  • Run go mod vendor after adding, updating, or removing dependencies.
  • Commit the vendor directory to version control.
  • Consider using vendoring for projects with strict deployment requirements or limited network connectivity.

When to Use Vendoring

Use vendoring when you need to ensure that your project can be built reliably, regardless of the availability of external dependencies. This is particularly important for critical projects or projects deployed in environments with limited network access.

Pros of Vendoring

  • Guaranteed build reproducibility: Ensures that the project can be built using the same versions of the dependencies, regardless of external factors.
  • Offline builds: Allows the project to be built even without internet access.
  • Isolation from dependency changes: Protects the project from unexpected changes in the upstream dependencies.

Cons of Vendoring

  • Increased repository size: The vendor directory can significantly increase the size of the repository.
  • Potential for conflicts: Conflicts can arise if the vendored dependencies are not properly managed.

← Go Modules: Managing Dependencies Importing with Aliases →

FAQ

  • What if I don't want to commit the vendor directory?

    While it's common to commit the vendor directory, you can choose not to. However, this means that anyone building the project will need to have access to the internet to download the dependencies.
  • How do I update vendored dependencies?

    Update the dependencies using go get, then run go mod vendor again to update the vendor directory.
  • Does vendoring affect build performance?

    Vendoring can slightly improve build performance by reducing the need to download dependencies from remote repositories.