golang-dependency-management
samber/cc-skills-golang
Manage Go dependencies safely: versioning, vulnerability scanning, conflict resolution, and automated updates.
What is golang-dependency-management?
Strategies for Go dependency management including go.mod/go.sum handling, package installation and upgrades, vulnerability auditing with govulncheck, and conflict resolution. Use when adding, removing, or upgrading dependencies, scanning for CVEs, resolving version conflicts, or setting up automated dependency updates.
- Add, upgrade, and remove Go dependencies with version control and safety checks
- Scan dependencies for known vulnerabilities using govulncheck before releases
- Manage go.mod and go.sum files, including vendoring for hermetic builds
- Resolve version conflicts using Minimal Version Selection (MVS) algorithm
- Track outdated dependencies and analyze binary size impact
- Set up automated dependency updates with Dependabot or Renovate
How to install golang-dependency-management
npx skills add https://github.com/samber/cc-skills-golang --skill golang-dependency-management- Go toolchain installed
- govulncheck: run `go install golang.org/x/vuln/cmd/govulncheck@latest`
How to use golang-dependency-management
- 1.Before adding any new dependency, ask the user for confirmation and evaluate if the standard library already solves the problem
- 2.Run `go get package@version` to add or upgrade a specific dependency
- 3.Run `go get -u=patch ./...` to safely upgrade all dependencies to latest patch versions
- 4.Run `go mod tidy` to add missing dependencies and remove unused ones
- 5.Run `govulncheck ./...` to scan for known CVEs before every release
- 6.Run `go mod vendor` if you need hermetic builds or offline deployment
- 7.For Go 1.24+, use `go get -tool` to pin CLI tools in go.mod; for older versions use tools.go
- 8.Commit both go.mod and go.sum to version control to ensure reproducible builds
Use cases
- Adding a new third-party package after confirming standard library doesn't cover it
- Upgrading all dependencies safely with patch-only updates and running tests
- Scanning a project for CVE vulnerabilities before a production release
- Resolving version conflicts when two dependencies require incompatible versions
- Setting up CI/CD to automatically check for outdated or vulnerable dependencies
- Go developers managing project dependencies
- DevOps engineers setting up dependency scanning in CI/CD
- Maintainers of production Go services
- Teams adopting automated dependency update workflows
golang-dependency-management FAQ
go.sum records cryptographic checksums of every dependency version. It lets `go mod verify` detect supply-chain tampering and ensures reproducible builds. Without it, a compromised proxy could silently substitute malicious code.
Prefer `go get -u=patch` for routine updates—it upgrades only to the latest patch version, which is lower risk than major or minor upgrades. Always run tests and `govulncheck` after upgrading.
Use vendoring when you need hermetic builds (no network access), reproducibility guarantees beyond checksums, or when deploying to environments without module proxy access. Commit the `vendor/` directory after running `go mod vendor`.
Run `go get package@none` to mark it for removal, then `go mod tidy` to clean up go.mod and go.sum.
Go 1.24+ supports `tool` directives in go.mod for pinning CLI tools reproducibly. For Go <1.24, use a `tools.go` file with blank imports as a fallback.
Full instructions (SKILL.md)
Source of truth, from samber/cc-skills-golang.
name: golang-dependency-management description: "Dependency management strategies for Golang projects — go.mod management, installing/upgrading packages, Minimal Version Selection, vulnerability scanning, outdated dependency tracking, binary size analysis, Dependabot/Renovate setup, conflict resolution, and go.work workspaces. Use when adding, removing, or upgrading Go dependencies, auditing vulnerabilities, resolving version conflicts, or setting up automated dependency updates." user-invocable: true license: MIT compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang. metadata: author: samber version: "1.2.4" openclaw: emoji: "📦" homepage: https://github.com/samber/cc-skills-golang requires: bins: - go - govulncheck install: - kind: go package: golang.org/x/vuln/cmd/govulncheck@latest bins: [govulncheck] allowed-tools: Read Edit Write Glob Grep Bash(go:) Bash(golangci-lint:) Bash(git:) Agent Bash(govulncheck:) AskUserQuestion
Persona: You are a Go dependency steward. You treat every new dependency as a long-term maintenance commitment — you ask whether the standard library already solves the problem before reaching for an external package.
Dependencies:
- govulncheck:
go install golang.org/x/vuln/cmd/govulncheck@latest
Go Dependency Management
AI Agent Rule: Ask Before Adding Dependencies
Before running go get to add any new dependency, AI agents MUST ask the user for confirmation. AI agents can suggest packages that are unmaintained, low-quality, or unnecessary when the standard library already provides equivalent functionality. Using go get -u to upgrade an existing dependency is safe.
Before proposing a dependency, evaluate:
- Does the standard library already cover the use case?
- Is the license compatible?
- Are there well-known alternatives?
- What it does and why it's needed?
The samber/cc-skills-golang@golang-popular-libraries skill contains a curated list of vetted, production-ready libraries. Prefer recommending packages from that list. When no vetted option exists, favor well-known packages from the Go team (golang.org/x/...) or established organizations over obscure alternatives.
Key Rules
go.sumMUST be committed — it records cryptographic checksums of every dependency version, lettinggo mod verifydetect supply-chain tampering. Without it, a compromised proxy could silently substitute malicious codegovulncheck ./...orgo tool govulncheck ./...before every release — catches known CVEs in your dependency tree before they reach production- Maintenance status, license compatibility, and stdlib alternatives are important considerations before adding a dependency — every dependency increases attack surface, maintenance burden, and binary size
go mod tidybefore every commit that changes dependencies — removes unused modules and adds missing ones, keeping go.mod honest
go.mod & go.sum
Essential Commands
| Command | Purpose |
|---|---|
go mod tidy | Add missing deps, remove unused ones |
go mod download | Download modules to local cache |
go mod verify | Verify cached modules match go.sum checksums |
go mod vendor | Copy deps into vendor/ directory |
go mod edit | Edit go.mod programmatically (scripts, CI) |
go mod graph | Print the module requirement graph |
go mod why | Explain why a module or package is needed |
Vendoring
Use go mod vendor when you need hermetic builds (no network access), reproducibility guarantees beyond checksums, or when deploying to environments without module proxy access. CI pipelines and Docker builds sometimes benefit from vendoring. Run go mod vendor after any dependency change and commit the vendor/ directory.
Installing & Upgrading Dependencies
Adding a Dependency
go get github.com/google/uuid # Latest version
go get github.com/google/uuid@v1.6.0 # Specific version
go get github.com/google/uuid@latest # Explicitly latest
go get github.com/google/uuid@<commit> # Specific commit (pseudo-version)
Before pinning a version, inspect the module's available versions, importers, and known vulnerabilities on pkg.go.dev → See samber/cc-skills-golang@golang-pkg-go-dev skill.
Upgrading
go get -u ./... # Upgrade ALL direct+indirect deps to latest minor/patch
go get -u=patch ./... # Upgrade to latest patch only (safer)
go get github.com/pkg@v1.5 # Upgrade specific package
Prefer go get -u=patch for routine updates. Patch and minor updates are usually lower risk than major upgrades, but still require review. For dependency updates, run:
go get -u=patch ./...
go mod tidy
go test ./...
go vet ./...
govulncheck ./... # or: go tool govulncheck ./...
Release notes and changelogs for libraries affecting persistence, serialization, networking, authentication, authorization, cryptography, or public APIs may contain important information about breaking changes.
Removing a Dependency
go get github.com/google/uuid@none # Mark for removal
go mod tidy # Clean up go.mod and go.sum
Installing CLI Tools
For Go 1.24+ modules, pin executable tools in go.mod with tool directives. Do not create a new tools.go blank-import file unless the module must support Go <1.24.
# Add tools to the current module.
go get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest
go get -tool golang.org/x/vuln/cmd/govulncheck@latest
go get -tool golang.org/x/perf/cmd/benchstat@latest
# Run pinned tools reproducibly.
go tool golangci-lint run ./...
go tool govulncheck ./...
go tool benchstat old.txt new.txt
# Install all module-pinned tools into GOBIN/PATH when needed.
go install tool
# Update pinned tools deliberately, then review go.mod/go.sum.
go get -u tool
go mod tidy
go.mod shape for a module targeting Go 1.26 or newer. This is an example target, not a cap; keep the project's actual go directive and do not change it just to add tools.
module example.com/project
go 1.26
tool (
github.com/golangci/golangci-lint/v2/cmd/golangci-lint
golang.org/x/vuln/cmd/govulncheck
golang.org/x/perf/cmd/benchstat
)
For Go <1.24 only, use the legacy tools.go blank-import workaround:
//go:build tools
package tools
import (
_ "github.com/golangci/golangci-lint/v2/cmd/golangci-lint"
_ "golang.org/x/vuln/cmd/govulncheck"
)
Rule: Go 1.24+ = tool directives. Go <1.24 = tools.go fallback.
Go 1.26+ module target note
When using a Go 1.26 or newer toolchain, go mod init may create a module with an older default go directive. If the project intentionally targets Go 1.26+ APIs, update the directive deliberately:
go mod edit -go=1.26
go mod tidy
For future Go versions, use the project's intended target version. Do not use APIs newer than the module's go directive until the project explicitly agrees to upgrade it.
Deep Dives
-
Versioning & MVS — Semantic versioning rules (major.minor.patch), when to increment each number, pre-release versions, the Minimal Version Selection (MVS) algorithm (why you can't just pick "latest"), and major version suffix conventions (v0, v1, v2 suffixes for breaking changes).
-
Auditing Dependencies — Vulnerability scanning with
govulncheck, tracking outdated dependencies, analyzing which dependencies make the binary large (goweight), and distinguishing test-only vs binary dependencies to keepgo.modclean. -
Dependency Conflicts & Resolution — Diagnosing version conflicts (what
go getdoes when you request incompatible versions), resolution strategies (replacedirectives for local development,excludefor broken versions,retractfor published versions that should be skipped), and workflows for conflicts across your dependency tree. -
Go Workspaces —
go.workfiles for multi-module development (e.g., library + example application), when to use workspaces vs monorepos, and workspace best practices. -
Automated Dependency Updates — Setting up Dependabot or Renovate for automatic dependency update PRs, auto-merge strategies (when to merge automatically vs require review), and handling security updates.
-
Visualizing the Dependency Graph —
go mod graphto inspect the full dependency tree,modgraphvizto visualize it, and interactive tools to find which dependency chains cause bloat.
Cross-References
- → See
samber/cc-skills-golang@golang-continuous-integrationskill for Dependabot/Renovate CI setup - → See
samber/cc-skills-golang@golang-securityskill for vulnerability scanning with govulncheck - → See
samber/cc-skills-golang@golang-popular-librariesskill for vetted library recommendations
Quick Reference
# Start a new module
go mod init github.com/user/project
# Add a dependency
go get github.com/google/uuid@v1.6.0
# Upgrade all deps (patch only, safer)
go get -u=patch ./...
# Remove unused deps
go mod tidy
# Check for vulnerabilities
govulncheck ./... # or: go tool govulncheck ./...
# Check for outdated deps
go list -u -m -json all | go-mod-outdated -update -direct
# Analyze binary size by dependency
goweight
# Understand why a dep exists
go mod why -m github.com/some/module
# Visualize dependency graph
go mod graph | modgraphviz | dot -Tpng -o deps.png
# Verify checksums
go mod verify
Related skills
More from samber/cc-skills-golang and the wider catalog.
golang-code-style
Go code style conventions for clarity, control flow, and readability—line breaking, variable declarations, and when comments help.
golang-error-handling
Idiomatic Go error handling: wrapping, inspection, structured logging, and production-grade error tracking.
golang-performance
Go performance optimization patterns: identify bottlenecks with profiling, then apply the right fix.
golang-design-patterns
Idiomatic Go design patterns: functional options, constructors, error handling, resource lifecycle, graceful shutdown, and resilience.
golang-testing
Production-ready Go tests with table-driven patterns, testify integration, parallel execution, fuzzing, and leak detection.
golang-security
Security best practices and vulnerability prevention for Go code—injection, crypto, secrets, and authentication.