Vendoring

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