go-dependency-injection
Skill85 starsChanged 18 days agoMITView on GitHub
Dependency injection in Go: constructor injection, wiring in main, avoiding global state, and when frameworks (wire, fx, dig) earn their complexity. Use when: "dependency injection", "wire up dependencies", "inject this", "remove global state", "singleton in Go", "use google/wire", "uber fx", "make this testable". Not for: interface design (go-interface-design), directory structure (go-project-layout), test doubles and mocks (go-test-quality).
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 55
Every dependency visible in the signature — if the list feels long, the type does too much (split it), don't hide deps to shorten it.
- Very specific: line 62
All wiring lives in one place — main (or a run function it calls).
- Distinctive: line 84
No package builds its own dependencies.
- Distinctive: line 149
Never mix models: one composition root, one mechanism.
- Distinctive: line 173
Every service/handler receives dependencies via constructor parameters
- Very specific: line 174
No package-level mutable singletons (var DB, var logger, Get() accessors)
- Very specific: line 175
All wiring concentrated in main/run — no init() construction
- Distinctive: line 179
If a DI tool is used: exactly one, at the composition root only
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Go Dependency Injection
DI in Go is a pattern, not a framework: pass dependencies to
constructors, wire everything explicitly in main. Reach for a
framework only when manual wiring measurably hurts.
Community default. A project skill or agent-config rule that explicitly supersedes
go-dependency-injectiontakes precedence over this one.
1. Constructor Injection — the Default
// ✅ Good — dependencies are explicit parameters
type OrderService struct {
repo OrderRepository
payments PaymentGateway
logger *slog.Logger
}
func NewOrderService(repo OrderRepository, payments PaymentGateway, logger *slog.Logger) *OrderService {
return &OrderService{repo: repo, payments: payments, logger: logger}
}
// ❌ Bad — hidden dependencies reached through globals
func (s *OrderService) Place(ctx context.Context, o Order) error {
db := database.Get() // global singleton
log.Printf("placing order") // global logger
// untestable without touching process-wide state
}Rules:
- Accept interfaces for dependencies the service calls; return the concrete type from the constructor.
- Every dependency visible in the signature — if the list feels long, the type does too much (split it), don't hide deps to shorten it.
- Validate required deps in the constructor and return an error
(or accept a nil-safe default, e.g.
logger = slog.Default()).
2. The Composition Root
All wiring lives in one place — main (or a run function it calls).
Construction order is the dependency order, checked by the compiler:
func run(ctx context.Context, cfg Config) error {
db, err := store.Open(ctx, cfg.DatabaseURL)
if err != nil {
return fmt.Errorf("open db: %w", err)
}
defer db.Close()
orderRepo := store.NewOrderRepo(db)
payments := stripe.NewGateway(cfg.StripeKey)
logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
orders := service.NewOrderService(orderRepo, payments, logger)
server := handler.NewServer(cfg.Addr, orders)
return server.ListenAndServe(ctx)
}- No package builds its own dependencies; it receives them.
- No
init()wiring, no package-levelvar DB *sql.DB. - Two binaries needing different wiring = two mains, same components.
3. Eliminating Global State
// ❌ Before — package-level singleton
var defaultClient *api.Client
func Fetch(id string) (*Item, error) {
return defaultClient.Get(id)
}
// ✅ After — the dependency moves into a struct
type Fetcher struct {
client *api.Client
}
func NewFetcher(c *api.Client) *Fetcher { return &Fetcher{client: c} }
func (f *Fetcher) Fetch(id string) (*Item, error) {
return f.client.Get(id)
}Migration path for a legacy codebase: introduce the struct, keep a
deprecated package-level wrapper delegating to one instance built in
main, move callers over, delete the wrapper.
Acceptable package-level state: pure constants, compiled regexps,
sync.Once-guarded process singletons that hold no config.
4. Function Dependencies for Small Seams
A full interface is overkill for one function — inject the function:
type Service struct {
now func() time.Time
genID func() string
publish func(ctx context.Context, e Event) error
}
// Production: Service{now: time.Now, genID: uuid.NewString, publish: bus.Publish}
// Test: Service{now: fixedTime, genID: constID, publish: capture}5. When Frameworks Earn Their Complexity
Manual wiring scales further than expected — a 100-line run function
is still readable and compiler-checked. Consider a tool when wiring
crosses hundreds of components or many teams share one binary.
| Tool | Model | Trade-off |
| google/wire | Compile-time code generation | Wiring stays plain Go and compiler-checked; adds a codegen step |
| uber-go/fx | Runtime container + lifecycle | App lifecycle (start/stop hooks) managed; errors surface at runtime, magic in stack traces |
| uber-go/dig | Runtime container (fx's core) | Same runtime trade-offs, no lifecycle layer |
Decision rule: prefer manual wiring; if generation becomes necessary prefer wire (failures at compile time beat failures at startup); adopt fx only when you also want its lifecycle management and your team accepts the runtime container.
Never mix models: one composition root, one mechanism.
6. Wire Example (when chosen)
//go:build wireinject
func InitializeServer(cfg Config) (*handler.Server, error) {
wire.Build(
store.Open,
store.NewOrderRepo,
stripe.NewGateway,
service.NewOrderService,
handler.NewServer,
)
return nil, nil // replaced by generated code
}wire generates the ordered constructor calls; the generated file is
committed and reviewed like handwritten code.
Verification Checklist
- Every service/handler receives dependencies via constructor parameters
- No package-level mutable singletons (
var DB,var logger,Get()accessors) - All wiring concentrated in main/run — no
init()construction - Dependencies accepted as interfaces (or funcs), concrete types returned
- Constructors validate required dependencies
- Components testable by passing fakes — no process-global setup in tests
- If a DI tool is used: exactly one, at the composition root only
go build ./...passes — wiring errors surface at compile time
In this repository38 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/go-skills.mdcCursor rule
- go-api-designSkill
- go-architecture-reviewSkill
- go-cliSkill
- go-design-patternsSkill
- go-graphqlSkill
- go-grpcSkill
- go-interface-designSkill
- go-openapiSkill
- go-project-layoutSkill
- go-code-reviewSkill
- go-coding-standardsSkill
- go-contextSkill
- go-data-structuresSkill
- go-documentationSkill
- go-error-handlingSkill
- go-modernizeSkill
- go-namingSkill
- go-databaseSkill
- go-concurrency-reviewSkill
- go-defensive-codingSkill
- go-observabilitySkill
- go-performance-reviewSkill
- go-security-auditSkill
- go-troubleshootingSkill
- go-test-qualitySkill
- go-test-table-drivenSkill
- git-commitSkill
- go-binary-sizeSkill
- go-build-releaseSkill
- go-ciSkill
- go-dependency-auditSkill
- go-refactoringSkill
- go-semantic-toolsSkill
- go-skills-routerSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

