Golang Google Wire

Google Wire maintenance

Use this skill for an existing Wire graph or a requested migration involving Wire. For new adoption, verify the upstream repository's current maintenance status and compatibility with the project's toolchain before recommending it.

Start from the repository

Before editing:

1. Inspect go.mod for the selected Wire version.
2. Locate injector files, provider sets, generated files, and the command the project uses to run Wire.
3. Check whether generated files are committed or produced by CI/build tooling.
4. Read nearby constructors and tests so provider ownership and cleanup behavior remain consistent.

Use the existing generation workflow and generated-file policy.

Preserve the graph model

• Providers are ordinary constructors. Keep their errors and cleanup functions meaningful outside Wire.
• Use provider sets to express intentional package boundaries; avoid exporting a broad set merely for convenience.
• Use wire.Bind when an interface is requested from a concrete implementation. Verify the binding against the selected Wire version.
• Distinguish multiple values of the same Go type with domain-specific named types or explicit wrapper types.
• Keep injector stubs behind the project's Wire build tag. Modern projects normally use //go:build wireinject; preserve any compatible legacy tag required by the repository.
• Treat generated output as derived code. Change providers or injectors, then regenerate; do not hand-edit generated functions.

For concrete provider signatures, wire.NewSet, wire.Bind, struct/value providers, injector stubs, and focused graph tests, read references/api-and-testing.md.

Cleanup and failure behavior

When providers return cleanup functions, verify the generated order and every error path. Construction failure may run cleanup for dependencies that were already created; the injector's returned cleanup is for a successfully constructed graph. Call it only after successful initialization and according to its actual signature.

Check the generated code and provider contract before assuming cleanup is non-nil, idempotent, or safe after partial initialization.

Changing or removing Wire

For a local graph change, update only the affected providers, sets, bindings, and injectors. For a migration away from Wire:

• retain constructor ordering, error propagation, and reverse-order cleanup;
• replace one composition root at a time when the repository permits incremental migration;
• compare generated code with the proposed manual wiring before deleting injectors;
• remove the dependency and generation steps only after no Wire imports, build tags, or generated references remain.

Verification

Run the repository's existing Wire command for the affected packages, then run formatting, compilation, and relevant tests. Review the generated diff for unexpected provider selection or cleanup changes. If the project commits generated output, verify it is current; otherwise verify the documented generation path works from a clean checkout.

Official references

• Wire repository and archive status
• Wire package documentation
• Wire user guide
• Wire best practices