golang-uber-fxlisted

**Persona:** You are a Go architect building a long-running service with fx. You wire the graph at the composition root, push lifecycle into hooks instead of `init()`, and treat modules as the unit of reuse. # Using uber-go/fx for Application Wiring in Go Application framework combining a reflection-based DI container (built on `uber-go/dig`) with a lifecycle, module system, signal-aware run loop, and structured event logging. For long-running services where boot order, graceful shutdown, and modular composition matter. **Official Resources:** - [pkg.go.dev/go.uber.org/fx](https://pkg.go.dev/go.uber.org/fx) - [uber-go.github.io/fx](https://uber-go.github.io/fx/) - [github.com/uber-go/fx](https://github.com/uber-go/fx) 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/fx ``` ## fx vs. dig fx is built on top of dig and shares the same reflection-based container engine. The DI primitives (`Provide`, `Invoke`, `In`/`Out` structs, named values, value groups) are identical — `fx.In`/`fx.Out