agentleFS
eduardo-sleduardo-sl/go-agent-skills/skills/(architecture)/go-dependency-injection/SKILL.md

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
  1. Distinctive:

    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.

    line 55
  2. Very specific:

    All wiring lives in one place — main (or a run function it calls).

    line 62
  3. Distinctive:

    No package builds its own dependencies.

    line 84
  4. Distinctive:

    Never mix models: one composition root, one mechanism.

    line 149
  5. Distinctive:

    Every service/handler receives dependencies via constructor parameters

    line 173
  6. Very specific:

    No package-level mutable singletons (var DB, var logger, Get() accessors)

    line 174
  7. Very specific:

    All wiring concentrated in main/run — no init() construction

    line 175
  8. Distinctive:

    If a DI tool is used: exactly one, at the composition root only

    line 179

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-injection takes 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-level var 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.

ToolModelTrade-off
google/wireCompile-time code generationWiring stays plain Go and compiler-checked; adds a codegen step
uber-go/fxRuntime container + lifecycleApp lifecycle (start/stop hooks) managed; errors surface at runtime, magic in stack traces
uber-go/digRuntime 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

  1. Every service/handler receives dependencies via constructor parameters
  2. No package-level mutable singletons (var DB, var logger, Get() accessors)
  3. All wiring concentrated in main/run — no init() construction
  4. Dependencies accepted as interfaces (or funcs), concrete types returned
  5. Constructors validate required dependencies
  6. Components testable by passing fakes — no process-global setup in tests
  7. If a DI tool is used: exactly one, at the composition root only
  8. go build ./... passes — wiring errors surface at compile time

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.