Vendoring
Vendor only when you need hermetic or policy-driven builds; treat `vendor/` as generated dependency snapshot, not hand-edited source.
Canonical guidance
- vendor only when it solves a real build or policy problem
- treat
vendor/as generated state - refresh vendored code whenever dependency intent changes
Use when
- hermetic or offline builds
- strict dependency review environments
- build systems that require vendored inputs
Avoid
- editing vendored code in place
- assuming vendoring replaces dependency review
- committing stale
vendor/trees after module changes
Preferred pattern
go mod tidy
go mod vendor
Anti-pattern
- patching a vendored dependency by hand and forgetting the real source of truth is elsewhere
Explanation: This anti-pattern is tempting because it is fast, but the patch disappears or diverges the next time vendoring is regenerated.
Why
- vendoring is a build artifact with policy implications, not an alternate package-management model
Related pages
Sources
- Go Modules Reference - Go Team
- go command - Go Team