Compile-time dependency injection in Golang using google/wire — wire.NewSet, wire.Build, wire.Bind (interface→concrete), wire.Struct, wire.Value, wire.InterfaceValue, wire.FieldsOf, cleanup functions, //go:build wireinject injector files, and generated wire_gen.go. Apply when using or adopting googl

Persona: You are a Go architect using wire for compile time DI. You let the compiler catch missing dependencies, treat wire gen.go as committed source, and re run wire ./... after every graph change. Dependencies: wire: go install github.com/google/wire/cmd/wire@latest Using google/wire for Compile Time Dependency Injection in Go Code generation DI toolkit. Wire resolves the dependency graph at compile time and emits plain Go constructor calls — no runtime container, no reflection. Errors appear when you run wire ./... , not at first request. Note: google/wire was archived in August 2025 (feature complete; bug fixes still accepted). Official Resources: [pkg.go.dev](https://pkg.go.dev/github.com/google/wire) · [github.com/google/wire](https://github.com/google/wire) · [User Guide](https://github.com/google/wire/blob/main/docs/guide.md) · [Best Practices](https://github.com/google/wire/blob/main/docs/best practices.md) 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. wire vs. Runtime DI Concern wire dig / fx / samber/do Resolution Compile time (codegen) Runtime (reflection) Error detection wire ./... fails First Invoke /startup Runtime container None — plain Go calls Present Lifecycle hooks Not built in fx: OnStart/OnStop Generated files wire gen.go (committed) None For lifecycle, lazy loading, and a full matrix see samber/cc skills golang@golang dependency injection . Providers A provider is any Go function — inputs are dependencies, outputs are provided types. Three return forms: Provider Sets wire.NewSet groups providers for reuse. Sets can reference other sets. Keep sets small: library sets expose a stable surface (adding inputs or removing outputs breaks downstream injectors). One set per package is a useful default. Injectors and //go:build wireinject The injector file declares the initialization function. Wire generates its body into wire gen.go and replaces the stub. The //go:build wireinject tag prevents the stub from being compiled into the binary — only wire gen.go (which has no such tag) makes it through go build . Without this tag, both files define the same function, causing a compile error. Alternative syntax when a dummy return is inconvenient: Interface Bindings Wire forbids implicit interface satisfaction — you must declare bindings explicitly so the graph is unambiguous when multiple types implement the same interface. Explicit bindings prevent graph breakage when a new type implementing the same interface is added elsewhere. Struct Providers and Values wire.Struct fills struct fields from the graph without a manual constructor. Tag fields wire:" " to exclude them. See [advanced.md](references/advanced.md) for the wire:" " exclusion tag and wire.FieldsOf details. Disambiguating Duplicate Types Wire forbids two providers for the same type. Wrap the underlying type in distinct named types so each has exactly one provider: Full Application Example Wire generates wire gen.go (plain Go, committed, DO NOT EDIT). For a full example with per package sets, cleanup heavy graphs, and generated output, see [recipes.md](references/recipes.md). Codegen Workflow Run wire ./... after every constructor signature change. Add //go:generate go run github.com/google/wire/cmd/wire to injector files so go generate ./... also works. Commit wire gen.go — it must stay in sync for CI builds. Best Practices 1. Never edit wire gen.go — it is overwritten on every wire ./... run. Treat it as a build artifact that happens to be committed; source of truth is the provider and injector files. 2. Always add //go:build wireinject to injector files — omitting it causes duplicate symbol compile errors because both the stub and the generated file define the same function. 3. Use named types to distinguish values of the same underlying type — wire enforces one provider per type; named types like type DSN string let you have PrimaryDSN and ReplicaDSN coexist. 4. Keep library provider sets minimal and backward compatible — adding new required inputs breaks downstream injectors; removing outputs does too. Introduce only newly created types in the same release. 5. Return (T, func(), error) from cleanup providers and let wire chain them — wire generates the correct reverse order cleanup and handles partial failures (if construction fails midway, only already built cleanups run). 6. Keep injector files focused — one function per file, one package import at a time. Fat injectors with dozens of wire.Build arguments are hard to reason about; delegate to per package sets. Common Mistakes Mistake Fix Editing wire gen.go manually Never edit it. Change providers or injectors and re run wire ./... . Missing //go:build wireinject Add the tag as the very first line of every injector file. Two providers returning sql.DB Wrap with a named struct type: type PrimaryDB struct { sql.DB } — Wire does not distinguish pointer type aliases. Injecting an interface without wire.Bind Add wire.Bind(new(MyInterface), new( MyImpl)) to the provider set. Forgetting to re run wire ./... after changes Run wire before go build ; add it to go generate or a Makefile target. Calling cleanup() without guarding for nil Wire returns nil cleanup on construction error; guard with if cleanup != nil { defer cleanup() } . Testing Wire generates plain Go constructors, so unit tests use manual injection — no container to clone or reset. For testing patterns (test injectors swapping real providers for fakes, CI stale check for wire gen.go ), see [testing.md](references/testing.md). Further Reading [advanced.md](references/advanced.md) — cleanup chains, multiple injectors, set nesting, error catalogue, codegen flags, quick reference [recipes.md](references/recipes.md) — HTTP server, multi injector build, cleanup heavy graph, CLI embedding [testing.md](references/testing.md) — test injectors, fake bindings, CI stale check Cross References → See samber/cc skills golang@golang dependency injection skill for DI concepts and library comparison → See samber/cc skills golang@golang uber dig skill for runtime reflection based DI without lifecycle → See samber/cc skills golang@golang uber fx skill for runtime DI with lifecycle hooks, modules, and signal aware Run() → See samber/cc skills golang@golang samber do skill for generics based DI without reflection → See samber/cc skills golang@golang structs interfaces skill for interface design patterns → See samber/cc skills golang@golang testing skill for general testing patterns If you encounter a bug or unexpected behavior in google/wire, open an issue at <https://github.com/google/wire/issues .

golang-google-wire