golang-uber-dig

Implements dependency injection in Go applications using the uber-go/dig reflection-based container.

Updated Jun 30, 2026
One-click install
npx skills add https://github.com/santoshkal/chezmoi --skill golang-uber-dig-santoshkal
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-uber-dig
Source: https://github.com/santoshkal/chezmoi/tree/main/private_dot_config/opencode/skills/Golang/skills/golang-uber-dig
Command: npx skills add https://github.com/santoshkal/chezmoi --skill golang-uber-dig-santoshkal

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, duplicated initialization code, and missing-dependency failures discovered only at runtime. This Skill guides correct use of uber-go/dig so constructors, named values, value groups, and scopes are registered and resolved correctly at startup. ## Core Features & Use Cases - Container Wiring Patterns: Covers Provide/Invoke, lazy memoized constructors, dig.In parameter objects, and dig.Out result objects for clean constructor signatures. - Advanced Graph Features: Named values for multiple instances of one type, value groups with flatten, dig.As interface exposure, Decorate, child scopes, and optional dependencies. - Testing & Validation: DryRun graph validation in CI, per-test containers, cycle detection, RootCause error unwrapping, and RecoverFromPanics handling. - Use Case: When building an HTTP server where many handlers must feed one router, use value groups so each handler constructor contributes to a shared slice without the router knowing which handlers exist. ## Quick Start Ask the assistant to wire your Go service's constructors with uber-go/dig using parameter objects and value groups instead of manual initialization in main.

Frequently Asked Questions about golang-uber-dig

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

FAQPage Schema
How do I use uber-go/dig for dependency injection in Go?▼

Create a container with dig.New(), register constructors with c.Provide, and resolve the graph with c.Invoke. Constructors are lazy and memoized, so each output type is built once and shared as a singleton per container.

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

fx is built on dig and shares the same DI primitives, but adds lifecycle hooks, modules, signal-aware Run(), and startup timeouts. Choose dig for CLI tools and libraries; choose fx for long-running services needing graceful shutdown.

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

Use dig.Name("primary") and dig.Name("readonly") as Provide options to disambiguate same-typed constructors. Consumers then add name:"primary" or name:"readonly" tags to dig.In struct fields.

How do I collect many providers into one slice with dig?▼

Tag a dig.Out field with group:"routes" so each constructor contributes to the group, and consume it as a slice field tagged group:"routes" in dig.In. Group order is not guaranteed; use an explicit ordered slice if order matters.

How do I validate a dig dependency graph without running constructors?▼

Create the test container with dig.New(dig.DryRun(true)), register the same providers as production, and call Invoke on the composition root. This catches missing providers and cycles without starting databases or servers.

When should I not pass the dig container into my services?▼

Never pass *dig.Container into business code; it belongs only at the composition root in main(). Injecting the container creates a service-locator anti-pattern that hides dependencies and breaks testability.