{"skill":{"slug":"golang-uber-dig","displayName":"Golang Uber Dig","summary":"Implements dependency injection in Golang using uber-go/dig — reflection-based container, Provide/Invoke, dig.In/dig.Out parameter and result objects, named...","description":"---\nname: golang-uber-dig\ndescription: \"Implements dependency injection in Golang using uber-go/dig — reflection-based container, Provide/Invoke, dig.In/dig.Out parameter and result objects, named values, value groups, optional dependencies, scopes, and Decorate. Apply when using or adopting uber-go/dig, when the codebase imports `go.uber.org/dig`, or when wiring an application graph at startup. For higher-level lifecycle and modules, see `samber/cc-skills-golang@golang-uber-fx` skill.\"\nuser-invocable: true\nlicense: MIT\ncompatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.\nmetadata:\n  author: samber\n  version: \"1.1.0\"\n  openclaw:\n    emoji: \"⛏️\"\n    homepage: https://github.com/samber/cc-skills-golang\n    requires:\n      bins:\n        - go\n    install: []\n    skill-library-version: \"1.19.0\"\nallowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs\n---\n\n**Persona:** You are a Go architect wiring an application graph with dig. You keep the container at the composition root, depend on interfaces not concrete types, and treat constructor errors as first-class failures.\n\n# Using uber-go/dig for Dependency Injection in Go\n\nReflection-based DI toolkit, designed to power application frameworks (it is the engine behind `uber-go/fx`) and resolve object graphs during startup.\n\n**Official Resources:**\n\n- [pkg.go.dev/go.uber.org/dig](https://pkg.go.dev/go.uber.org/dig)\n- [github.com/uber-go/dig](https://github.com/uber-go/dig)\n\nThis skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.\n\n```bash\ngo get go.uber.org/dig\n```\n\n## dig vs. fx\n\nfx is built on dig and shares the same container engine — the DI primitives (`Provide`, `Invoke`, `In`/`Out` structs, named values, value groups) are identical. `fx.In`/`fx.Out` are re-exports of `dig.In`/`dig.Out`.\n\nWhat fx adds on top of dig:\n\n| Concern | dig | fx |\n| --- | --- | --- |\n| DI container | ✅ `dig.New()` | ✅ (embedded) |\n| Lifecycle hooks | ❌ | ✅ `fx.Lifecycle` OnStart/OnStop |\n| Module system | ❌ | ✅ `fx.Module` with scoped decorators |\n| Signal-aware run loop | ❌ | ✅ `app.Run()` blocks on SIGINT/SIGTERM |\n| Structured event logging | ❌ | ✅ `fx.WithLogger` / `fxevent` |\n| Startup/shutdown timeout | ❌ | ✅ `fx.StartTimeout` / `fx.StopTimeout` |\n\n**Choose dig** when you need the wiring graph only: CLI tools, libraries exposing a container to callers, test harnesses, or embedding DI into an existing app that manages its own lifecycle.\n\n**Choose fx** for long-running services (HTTP servers, workers, daemons) — lifecycle and signal handling are non-negotiable there. See `samber/cc-skills-golang@golang-uber-fx` skill.\n\n## Container\n\n```go\nimport \"go.uber.org/dig\"\n\nc := dig.New()\n```\n\nUseful options: `dig.DeferAcyclicVerification()` (faster startup), `dig.RecoverFromPanics()` (turn panics into `dig.PanicError`), `dig.DryRun(true)` (validate without invoking).\n\n## Provide and Invoke\n\n```go\n// Register a constructor — lazy, only runs when its output is needed\nerr := c.Provide(func(cfg *Config) (*sql.DB, error) {\n    return sql.Open(\"postgres\", cfg.DSN)\n})\n\n// Pull a service out of the container by asking for it as a function parameter\nerr = c.Invoke(func(db *sql.DB) error {\n    return db.Ping()\n})\n```\n\nConstructors are **lazy** and **memoized**: each output type is built once and shared (singleton per container). `Provide` errors at registration if the constructor is malformed; `Invoke` returns the constructor's error wrapped with the dependency path that triggered it.\n\nA dig constructor is any function. Inputs are dependencies, outputs are provided types. `error` (last return) signals construction failure. Follow \"accept interfaces, return structs\".\n\n## Parameter Objects with `dig.In`\n\nOnce a constructor has 4+ dependencies, embed `dig.In` to group them as struct fields and tag fields:\n\n```go\ntype HandlerParams struct {\n    dig.In\n\n    Logger *zap.Logger\n    DB     *sql.DB\n    Cache  *redis.Client `optional:\"true\"`           // zero value if not provided\n    DBRO   *sql.DB       `name:\"readonly\"`           // named dependency\n    Routes []http.Handler `group:\"routes\"`           // value group\n}\n\nfunc NewHandler(p HandlerParams) *Handler { /* ... */ }\n```\n\nTags: `name:\"...\"`, `optional:\"true\"`, `group:\"...\"`.\n\n## Result Objects with `dig.Out`\n\nReturn several values from one constructor and attach `name`/`group` tags to results:\n\n```go\ntype ConnResult struct {\n    dig.Out\n\n    ReadWrite *sql.DB `name:\"primary\"`\n    ReadOnly  *sql.DB `name:\"readonly\"`\n}\n\nfunc NewConnections(cfg *Config) (ConnResult, error) { /* ... */ }\n```\n\n## Named Values\n\nTwo providers of the same type collide. Disambiguate with `dig.Name`:\n\n```go\nc.Provide(NewPrimaryDB,  dig.Name(\"primary\"))\nc.Provide(NewReadOnlyDB, dig.Name(\"readonly\"))\n```\n\nConsume by adding `name:\"primary\"` / `name:\"readonly\"` to a `dig.In` field.\n\n## Value Groups\n\nMany providers, one consumer slice — typical for HTTP handlers, health checks, migrations:\n\n```go\ntype RouteResult struct {\n    dig.Out\n    Handler http.Handler `group:\"routes\"`\n}\n\nfunc NewUserHandler(db *sql.DB) RouteResult { /* ... */ }\nfunc NewPostHandler(db *sql.DB) RouteResult { /* ... */ }\n\ntype ServerParams struct {\n    dig.In\n    Routes []http.Handler `group:\"routes\"`\n}\n```\n\n**Flatten** — append `,flatten` (e.g. `group:\"routes,flatten\"`) to unwrap a slice instead of nesting it. Group order is **not guaranteed**; if order matters, provide an explicit ordered slice from a single constructor.\n\n## Provide as Interface (`dig.As`)\n\nRegister a concrete constructor and expose it under one or more interfaces without a separate adapter:\n\n```go\nc.Provide(NewPostgresDB, dig.As(new(Database), new(io.Closer)))\n// Consumers ask for Database or io.Closer; *PostgresDB stays hidden.\n```\n\n## Full Application Example\n\n```go\nfunc main() {\n    c := dig.New()\n\n    must(c.Provide(NewConfig))\n    must(c.Provide(NewLogger))\n    must(c.Provide(NewDatabase))\n    must(c.Provide(NewServer))\n\n    err := c.Invoke(func(srv *http.Server) error {\n        return srv.ListenAndServe()\n    })\n    if err != nil {\n        log.Fatal(err)\n    }\n}\n\nfunc must(err error) { if err != nil { panic(err) } }\n```\n\ndig has **no built-in lifecycle**. If you need OnStart/OnStop hooks, signal handling, and graceful shutdown, use fx — see `samber/cc-skills-golang@golang-uber-fx` skill.\n\nFor Decorate, Scopes, optional deps, error helpers, and Visualize, see [advanced.md](./references/advanced.md).\n\n## Best Practices\n\n1. Keep the container at the composition root — never pass `*dig.Container` as a parameter; treat it like a plumbing detail of `main()`. Service-locator patterns defeat the testability gains of DI.\n2. Depend on interfaces, not concrete types — lets you swap implementations in tests without touching production code, and lets you use `dig.As` to expose narrow interfaces from wide structs.\n3. Prefer parameter objects (`dig.In` structs) once a constructor has 4+ dependencies — call sites stay readable and adding a new dependency is a one-line change instead of a signature break.\n4. Group registration by module (one file per module that calls `c.Provide` for its types) — review and refactoring become a per-module concern, and you can extract a module into a fx.Module later without rewriting wiring.\n5. Validate the graph eagerly in tests — call `c.Invoke` against the composition root in CI to surface missing providers at boot time, not at first request. `DryRun(true)` skips constructor execution.\n6. Return errors from constructors instead of panicking — dig wraps them with the dependency path, which makes the failure point obvious.\n\n## Common Mistakes\n\n| Mistake | Fix |\n| --- | --- |\n| Passing the container into services | The container belongs to `main()`. Inject the typed dependencies a service needs; otherwise tests need to build a real container. |\n| Two providers for the same type without `Name` | dig errors at `Provide` time. Either name them, or merge into a single provider that returns a `dig.Out` result struct. |\n| Ignoring `Provide` errors | Wrap each `Provide` with a `must` helper. A silent registration error becomes a missing-type error far later. |\n| Using groups when ordering matters | Groups are unordered. If order matters (middleware chain, migration sequence), provide an explicit ordered slice with one constructor. |\n| Constructors with side effects on import | Keep `init()` empty — start work only inside the constructor, after the graph is built. |\n\n## Testing\n\ndig containers are cheap — build a fresh one per test, override providers with `Decorate`, and call `Invoke` to drive the system. For full patterns (per-test wiring, shared helpers, graph validation in CI, asserting wire-time errors, recovering from constructor panics), see [testing.md](./references/testing.md).\n\n## Further Reading\n\n- [advanced.md](./references/advanced.md) — Decorate, Scopes, optional deps, error helpers, Visualize, full Quick Reference\n- [recipes.md](./references/recipes.md) — end-to-end examples: HTTP server with route group, two databases, request scopes, decorators, dry-run validation\n- [testing.md](./references/testing.md) — testing patterns and graph validation\n\n## Cross-References\n\n- → See `samber/cc-skills-golang@golang-uber-fx` skill for application lifecycle, modules, and signal-aware Run() built on top of dig\n- → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI concepts and library comparison\n- → See `samber/cc-skills-golang@golang-samber-do` skill for a generics-based alternative without reflection\n- → See `samber/cc-skills-golang@golang-google-wire` skill for compile-time DI (no runtime container)\n- → See `samber/cc-skills-golang@golang-structs-interfaces` skill for interface design patterns\n- → See `samber/cc-skills-golang@golang-testing` skill for general testing patterns\n\nIf you encounter a bug or unexpected behavior in uber-go/dig, open an issue at <https://github.com/uber-go/dig/issues>.\n","tags":{"latest":"1.1.0"},"stats":{"comments":0,"downloads":337,"installsAllTime":0,"installsCurrent":0,"stars":0,"versions":1},"createdAt":1777675276944,"updatedAt":1778492826217},"latestVersion":{"version":"1.1.0","createdAt":1777675276944,"changelog":"- Expanded documentation and best practices for using the uber-go/dig dependency injection container in Go projects.\n- Added sections on parameter/result objects (`dig.In`/`dig.Out`), named values, value groups, optional dependencies, and interface registration (`dig.As`).\n- Now includes direct feature comparison and migration guidance for switching between dig and fx.\n- Provides concrete code examples, diagrams, and recommendations for typical DI patterns in Go.\n- Clarifies use cases for dig versus fx, linking to an advanced reference for further topics.\n- Updated metadata for improved discoverability and alignment with latest standards.","license":"MIT-0"},"metadata":{"setup":[],"os":null,"systems":null},"owner":{"handle":"samber","userId":"s173arkhs3131fq5jf769qq75583hdgt","displayName":"Samuel Berthe","image":"https://avatars.githubusercontent.com/u/2951285?v=4"},"moderation":null}