go-uber-dig

Wire Go application dependency graphs using the uber-go/dig reflection-based container.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve? Wiring a Go application's object graph by hand leads to tangled constructors, hidden initialization order, and missing-dependency failures that surface only at runtime. This Skill guides correct use of uber-go/dig so the container is built once at the composition root, constructors are registered and validated, and errors fail fast at boot instead of at first request. ## Core Features & Use Cases - Graph construction and registration: Create the container in main(), register constructors with Provide, and resolve the graph with Invoke, including dig.In/dig.Out parameter and result structs. - Advanced wiring patterns: Named values for same-type collisions, value groups for many-to-one wiring, dig.As to expose interfaces, optional dependencies, Decorate, and child scopes. - Review and testing workflows: Audit containers for service-locator anti-patterns and ignored errors, validate graphs in CI with DryRun, and override dependencies per test with Decorate. - Use Case: You are building an HTTP server where many handlers each contribute a route. Register each handler with a group:"routes" tag, consume the collected slice in the server constructor, and validate the whole graph in a CI test using dig.DryRun(true). ## Quick Start Ask the assistant to wire your Go application's dependencies with uber-go/dig, registering constructors in main and validating the graph with a dry-run Invoke.

Frequently Asked Questions about go-uber-dig

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

FAQPage Schema
How do I wire dependencies in Go with uber-go/dig?

Create a container with dig.New() in main(), register constructors with c.Provide(fn) where inputs are dependencies and outputs are provided types, then call c.Invoke to run a function with injected dependencies. Check every Provide error at registration time.

What is the difference between dig and fx in Go?

dig is only a reflection-based DI container, while fx adds lifecycle hooks (OnStart/OnStop), modules, signal-aware Run(), and startup timeouts on top of dig. Choose dig for CLI tools and libraries; choose fx for long-running services.

How do I provide two instances of the same type in dig?

Register each provider with dig.Name, for example dig.Name("primary") and dig.Name("readonly"), and consume them through dig.In fields tagged with the matching name. Without names, two providers of the same type fail at Provide time.

Are dig value groups ordered in Go?

No, value group order is not guaranteed in dig. If ordering matters, such as middleware chains or migration sequences, provide an explicit ordered slice from a single constructor instead of relying on a group.

How do I test code that uses a dig container?

Build a fresh container per test, provide fakes for external dependencies, and use Decorate to swap implementations. Validate the production graph in CI with dig.New(dig.DryRun(true)) so missing providers fail without running constructors.

When should I not use uber-go/dig?

Avoid dig when you need lifecycle management, signal handling, or graceful shutdown, since dig has no built-in lifecycle; use fx instead. Also avoid passing the container into services, which defeats testability.