go-uber-fx

Wire Go applications with uber-go/fx dependency injection and lifecycle hooks.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires go.uber.org/fx, and includes references (resource) components.

What problem does it solve? Building long-running Go services requires coordinating dependency wiring, boot order, and graceful shutdown by hand. This Skill guides you through structuring an application with uber-go/fx so constructors, lifecycle hooks, and modules stay correct and maintainable. ## Core Features & Use Cases - Application Wiring: Compose apps with fx.New, fx.Provide, fx.Invoke, and signal-aware app.Run() with configurable start/stop timeouts. - Lifecycle Management: Register OnStart/OnStop hooks via fx.Lifecycle, keep hooks non-blocking, and honor context cancellation for graceful shutdown. - Modules and Annotations: Organize providers into fx.Module with scoped decorators, and use fx.Annotate with name/group tags, fx.As interface binding, and value groups. - Testing and Validation: Validate the graph in CI with app.Err(), and test with fxtest, fx.Replace, fx.Populate, and standalone lifecycles. - Use Case: You are building an HTTP service with a database, metrics, and background workers. Use this Skill to wire the full graph with modules, register graceful shutdown hooks, and add a CI test that fails on missing providers. ## Quick Start Ask the AI to wire a Go HTTP server with uber-go/fx including lifecycle hooks for startup and graceful shutdown.

Frequently Asked Questions about go-uber-fx

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

FAQPage Schema
How do I wire a Go application with uber-go/fx?

Compose the app with fx.New(fx.Provide(...), fx.Invoke(...)) and call app.Run(), which blocks on SIGINT/SIGTERM and fires OnStop hooks. Constructors registered with fx.Provide run lazily, so at least one fx.Invoke must reference each type for its constructor to execute.

What is the difference between uber-go/fx and dig?

dig is a raw dependency injection container, while fx embeds dig and adds lifecycle hooks, a module system with scoped decorators, a signal-aware run loop, structured event logging, and start/stop timeouts. Choose fx for long-running services and dig for CLI tools or libraries managing their own lifecycle.

How do I register OnStart and OnStop hooks in fx?

Inject fx.Lifecycle into a constructor and call lc.Append with an fx.Hook containing OnStart and OnStop callbacks. Keep OnStart non-blocking by spawning goroutines for long-running work, and respect the context passed to each hook since it is bounded by StartTimeout and StopTimeout.

Why is my fx constructor never running?

Constructors registered with fx.Provide are lazy and only run when reachable from an fx.Invoke, directly or transitively. Add at least one Invoke per application that references the type, or use fx.Populate in tests to pull values from the graph.

How do I test an fx application with fxtest?

Use fxtest.New(t, opts...) so wiring errors fail the test instead of crashing, then call app.RequireStart() and defer app.RequireStop(). Swap real dependencies with fx.Replace, extract values with fx.Populate, or use fxtest.NewLifecycle(t) to test a single constructor's hooks in isolation.

When should I use fx.Supply instead of fx.Provide?

Use fx.Supply for pre-built values such as parsed config, secrets, and command-line flags instead of writing a no-op constructor that returns them. fx.Supply makes these values first-class graph members and keeps constructors reserved for actual construction logic.