golang-uber-diglisted

**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. # Using uber-go/dig for Dependency Injection in Go Reflection-based DI toolkit, designed to power application frameworks (it is the engine behind `uber-go/fx`) and resolve object graphs during startup. **Official Resources:** - [pkg.go.dev/go.uber.org/dig](https://pkg.go.dev/go.uber.org/dig) - [github.com/uber-go/dig](https://github.com/uber-go/dig) This skill is not exhaustive — refer to library documentation and code examples for more information: - For Go package docs, symbols, versions, importers, and known vulnerabilities, → See `samber/cc-skills-golang@golang-pkg-go-dev` skill (`godig`), preferred over Context7 for Go package facts. - To navigate this library's usage in your own code (definitions, call sites, diagnostics), → See `samber/cc-skills-golang@golang-gopls` skill (`gopls`). - Context7 remains a fallback for docs not indexed on pkg.go.dev. ```bash go get go.uber.org/dig ``` ## dig vs. fx fx 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`. What fx adds on top of dig: | Concern | dig | fx | | --- | --- | --- | | DI container | ✅ `dig.New()` | ✅ (embedded) | | Lifecycle hooks | ❌