golang-uber-dig

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

Updated May 9, 2026
One-click install
npx skills add https://github.com/LuminaVault/LuminaVaultShared --skill golang-uber-dig-luminavault
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-uber-dig
Source: https://github.com/LuminaVault/LuminaVaultShared/tree/main/.agents/skills/golang-uber-dig
Command: npx skills add https://github.com/LuminaVault/LuminaVaultShared --skill golang-uber-dig-luminavault

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 wired declaratively at the composition root. ## Core Features & Use Cases - Container Wiring: Register lazy, memoized constructors with Provide and resolve graphs with Invoke, using dig.In/dig.Out parameter and result objects. - Advanced Graph Patterns: Disambiguate same-typed providers with dig.Name, fan in many providers with value groups and flatten, hide concrete types behind interfaces with dig.As, and isolate per-request state with scopes and Decorate. - Validation & Testing: Validate the production graph in CI with dig.DryRun, detect cycles, recover constructor panics as typed errors, and visualize failed graphs in DOT format. - Use Case: A Go HTTP service needs two *sql.DB connections (primary and read-only) plus a router consuming all registered handlers. Use named values for the databases and a value group for routes so main() never assembles slices manually. ## Quick Start Ask the AI to wire your Go application's constructors with uber-go/dig using Provide, Invoke, and dig.In parameter objects at the composition root.

Frequently Asked Questions about golang-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?▼

Register constructors with c.Provide and resolve the graph with c.Invoke at the composition root. Constructors are lazy and memoized, returning their output type plus an optional error, and dig injects dependencies by matching parameter types.

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 providers like two *sql.DB connections. Consumers then add name:"primary" or name:"readonly" tags to dig.In struct fields.

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

fx is built on dig and shares the same container 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 collect many providers into one slice with dig?▼

Tag result struct fields with group:"routes" so each constructor contributes one entry, and consume them as a slice field tagged with the same group in a dig.In struct. Group order is not guaranteed; use ",flatten" to unwrap slice results.

How do I test dig wiring without starting real services?▼

Create the container with dig.New(dig.DryRun(true)), register the same providers as production, and call Invoke on the composition root. dig validates the graph structurally without executing constructors, catching missing providers in CI.

Should I pass the dig container into my services?▼

No. The container belongs only at the composition root in main(); injecting it into handlers creates a service-locator anti-pattern that hides dependencies and breaks testability. Inject typed dependencies as constructor parameters instead.