go-dependency-injection

Designs Go dependency injection wiring using constructors, wire, dig/fx, or samber/do.

1|2|Updated Nov 25, 2017
One-click install
npx skills add https://github.com/asarchami/dotfiles --skill go-dependency-injection-asarchami
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: go-dependency-injection
Source: https://github.com/asarchami/dotfiles/tree/main/dot_config/opencode/skills/go/go-dependency-injection
Command: npx skills add https://github.com/asarchami/dotfiles --skill go-dependency-injection-asarchami

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Go services often accumulate hidden dependencies through global variables, init() functions, and concrete-type coupling, making them hard to test and refactor. This Skill provides a structured method to design or refactor dependency injection so every service declares what it needs and wiring lives in one composition root. ## Core Features & Use Cases - Design new wiring: Map the dependency graph, classify singletons vs transients, and choose between manual constructors, google/wire, uber-go/dig+fx, or samber/do using a decision table. - Refactor coupled code: Locate globals, init() setup, and service-locator patterns, then migrate incrementally to constructor injection. - Library deep dives: Reference guides cover manual DI layering, wire code generation, dig/fx lifecycle hooks and modules, and samber/do generics-based containers. - Use Case: When a Go service grows past 15 components and main() wiring becomes fragile, use this Skill to justify adopting a DI library and migrate services step by step while keeping tests mockable. ## Quick Start Ask the AI to design dependency injection wiring for your Go service graph or to refactor init()-heavy code into constructor-injected services.

Frequently Asked Questions about go-dependency-injection

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement dependency injection in Go?

Pass dependencies through constructors that accept interfaces and return structs, then wire everything in main() at the composition root. For small projects under 10 services, manual constructor injection is sufficient without any library.

google/wire vs uber-go/fx vs samber/do for Go DI?

Wire generates code at compile time with no reflection but requires a build step. Fx uses reflection with built-in lifecycle hooks and modules. Samber/do uses generics for compile-time safety with lazy loading, health checks, and container cloning.

When should I adopt a DI library in Go?

Stay manual below 10 services. Consider a library at 10-20 services with cross-cutting concerns, and strongly adopt one past 20 services or when you need health checks, graceful shutdown, lazy loading, or scopes.

Does google/wire support lazy loading and lifecycle management?

No. Wire creates all dependencies eagerly and has no built-in lifecycle management, health checks, or graceful shutdown. It generates plain Go constructor calls, so lifecycle handling must be written manually.

Why is passing the DI container to services an anti-pattern?

Passing the container turns it into a service locator, hiding each component's real dependencies. Inject only the specific dependencies each service needs through its constructor so requirements stay explicit and testable.

How do I refactor Go code with init() and global dependencies?

Inventory every global and init()-created dependency, define interfaces at consumption points, then convert services to constructor injection incrementally. Move all wiring into main() and verify each service builds in tests with mocks.