If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/google/wire shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 9mo ago
• 26+ active contributors
• Distributed ownership (top contributor 36% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 9mo ago

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live google/wire repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/google/wire.

What it runs against: a local clone of google/wire — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in google/wire | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 290 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of google/wire. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/google/wire.git
#   cd wire
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of google/wire and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "google/wire(\\.git)?\\b" \\
  && ok "origin remote is google/wire" \\
  || miss "origin remote is not google/wire (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "cmd/wire/main.go" \\
  && ok "cmd/wire/main.go" \\
  || miss "missing critical file: cmd/wire/main.go"
test -f "internal/wire/analyze.go" \\
  && ok "internal/wire/analyze.go" \\
  || miss "missing critical file: internal/wire/analyze.go"
test -f "internal/wire/parse.go" \\
  && ok "internal/wire/parse.go" \\
  || miss "missing critical file: internal/wire/parse.go"
test -f "internal/wire/copyast.go" \\
  && ok "internal/wire/copyast.go" \\
  || miss "missing critical file: internal/wire/copyast.go"
test -f "docs/guide.md" \\
  && ok "docs/guide.md" \\
  || miss "missing critical file: docs/guide.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 290 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~260d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/google/wire"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Wire is a compile-time dependency injection code generator for Go that eliminates boilerplate initialization code by analyzing function signatures and automatically generating dependency graphs. It generates wire_gen.go files that wire together components using explicit dependency declarations rather than reflection or global state, making initialization fast and safe at compile time. Single-module design: cmd/wire/main.go is the CLI entry point; internal/wire/{analyze.go, parse.go} contain the core code generation logic; internal/wire/testdata/ has ~50+ test cases with expected wire_gen.go outputs; _tutorial/ demonstrates the feature with main.go and wire.go. The tool reads wire.go files (user declarations) and generates wire_gen.go (initialization code).

Go backend developers building modular applications who want type-safe, compile-time verified dependency injection without the overhead of reflection-based frameworks like Uber's dig. Teams that value explicit initialization code and compile-time safety over runtime flexibility.

Wire is feature-complete but officially unmaintained as of v0.3.0 (beta status). The project explicitly states it will not accept new features and prefers community forks for extensions. It has comprehensive test coverage (internal/wire/testdata), CI/CD via GitHub Actions (tests.yml), and is well-documented with tutorial, guide, and best-practices docs—production-ready but frozen for new features.

Critical risk: project is officially unmaintained and no longer accepting updates beyond bug fixes. Dependency on golang.org/x/tools (v0.24.1) means compiler/toolchain changes could break Wire without fixes. Small active maintainer pool increases single-point-of-failure risk. Go 1.19+ is required (go.mod), so older projects must upgrade to use it.

Project is in maintenance-only mode. No active feature development; maintainers focus on bug fixes and security issues if reported. The repository accepts pull requests for fixes but will not merge feature requests.

go install github.com/google/wire/cmd/wire@latest
cd /tmp && git clone https://github.com/google/wire.git
cd wire
go build ./cmd/wire
./wire ./_tutorial

Daily commands:

go install ./cmd/wire
wire ./path/to/your/package

This scans for wire.go in the target package, analyzes dependencies, and generates wire_gen.go. No server; this is a CLI tool that exits after code generation.

• cmd/wire/main.go — Entry point for the Wire CLI tool; every contributor must understand how the wire command is invoked and routes to core analysis logic.
• internal/wire/analyze.go — Core dependency analysis engine that determines provider-to-consumer relationships; the heart of Wire's compile-time DI logic.
• internal/wire/parse.go — Parses wire.go files to extract injector definitions, providers, and bindings; critical for understanding the input format.
• internal/wire/copyast.go — Generates the wire_gen.go output file by copying and adapting AST nodes; essential for understanding code generation mechanics.
• docs/guide.md — User-facing documentation on Wire concepts and API; required reading to understand the tool's philosophy and usage patterns.
• go.mod — Defines minimal dependencies (go-cmp, subcommands, go/tools); shows Wire's intentional lightweight design.
• README.md — Project overview stating Wire is no longer maintained; critical context for all contributors.

• parse.go (Go AST, golang.org/x/tools) — Extracts injector declarations, provider calls, and binding directives from wire.go files.
  • Failure mode: Syntax errors, unsupported directives → user-facing parse errors reported to stderr.
• analyze.go (Go types, graph algorithms (DFS)) — Builds the dependency graph, resolves providers to consumers, detects cycles, validates type compatibility.
  • Failure mode: Cyclic dependencies, missing providers, type mismatches → errors block wire_gen.go generation.
• copyast.go (Go AST, code formatting) — Traverses the dependency graph and generates executable Go code (wire_gen.go) by copying and adapting AST nodes.
  • Failure mode: Code generation bugs → malformed wire_gen.go, compile errors when user builds their package.
• cmd/wire/main.go (Go flags, golang.org/x/tools/packages) — CLI orchestrator: loads packages, invokes parser and analyzer, writes output, reports errors.
  • Failure mode: Package loading errors, file I/O errors → wire command exits with error status.

• Developer's wire.go file → wire CLI — User defines injectors and providers in wire.go using Wire directives.
• wire CLI → parse.go — CLI invokes parser to extract AST nodes and identify providers, injectors, bindings.
• parse.go → analyze.go — Parser passes extracted provider and injector info to analyzer for dependency resolution.
• analyze.go → copyast.go — Analyzer passes validated dependency graph to code generator.
• copyast.go → wire_gen.go (generated file) — Generator outputs wire_gen.go containing the initialized injector functions.
• wire_gen.go → User's main.go or application code — Generated injector functions are imported and called to initialize the application.

Add a new testdata case for a Wire feature

1. Create a new directory under internal/wire/testdata/, e.g., internal/wire/testdata/MyFeature/ (internal/wire/testdata)
2. Create foo/ subdirectory with foo.go (provider definitions) and wire.go (injector declaration) (internal/wire/testdata/MyFeature/foo)
3. Create want/wire_gen.go with the expected generated code and want/program_out.txt with expected program output (internal/wire/testdata/MyFeature/want/wire_gen.go)
4. The test harness in internal/wire/ will automatically discover and validate your testdata directory (internal/wire/analyze.go)

Add support for a new Wire directive or binding type

1. Add AST parsing logic in internal/wire/parse.go to recognize your new directive syntax (internal/wire/parse.go)
2. Extend the analyze.go dependency graph logic to handle the new binding semantics (internal/wire/analyze.go)
3. Update copyast.go to generate correct code for your binding in wire_gen.go output (internal/wire/copyast.go)
4. Add a new testdata case under internal/wire/testdata/ to validate the feature end-to-end (internal/wire/testdata)

Fix a bug in dependency resolution

1. Write a failing testdata case in internal/wire/testdata/ that reproduces the bug (internal/wire/testdata)
2. Identify the root cause in internal/wire/analyze.go (provider lookup, cycle detection, or type matching) (internal/wire/analyze.go)
3. Update the logic and re-run tests to confirm the testdata case now passes (internal/wire/analyze.go)

• Go AST (golang.org/x/tools) — Wire operates as a compile-time code generator; AST manipulation is required to parse wire.go declarations and generate wire_gen.go.
• Dependency on google/go-cmp — Used for test comparisons when validating generated code against golden files in testdata directories.
• google/subcommands — Provides CLI framework for the wire command with consistent flag parsing and help text.

• Compile-time DI vs. runtime reflection

  • Why: Wire deliberately avoids runtime reflection to keep generated code simple, fast, and debuggable.
  • Consequence: Requires a build step; cannot dynamically swap implementations at runtime without regeneration.

• Code generation rather than library approach

  • Why: Generates explicit initialization code so dependencies are visible in the source; encourages understanding and testing of component wiring.
  • Consequence: Generated wire_gen.go files must be kept in version control and regenerated when wire.go changes; adds build complexity.

• No runtime state or global variables

  • Why: Promotes explicit initialization and makes hand-written initialization code equally useful.
  • Consequence: User code must be structured to pass all dependencies as parameters; incompatible with legacy global-state patterns.

• Does not support dynamic/runtime dependency resolution; all wiring is determined at compile time.
• Does not handle authentication, authorization, or security concerns; purely a code generation utility.
• Does not provide a runtime container or lifecycle management beyond cleanup functions.
• Does not integrate with external dependency management systems (e.g., service meshes, container orchestrators).
• Project is no longer maintained; no new features are planned.

• Global initialization in wire.go — User code pattern (not in Wire: undefined

1. Wire is a code generation tool, not a runtime framework—generated wire_gen.go must be committed to version control and re-run when dependencies change (easy to forget). 2) Injectors must be declared in a file named wire.go in the target package; the tool scans by convention, not configuration. 3) Go 1.19+ required; projects on older versions will fail silently or with cryptic errors. 4) Generated code uses unexported names (wiring_MyInjector) so direct manipulation breaks on regeneration. 5) Circular dependency detection happens at generation time, but the error messages can be opaque if you nest Struct fields deeply.

• Compile-time Dependency Injection — Wire's core distinction: DI resolved at code generation time, not runtime, eliminating reflection overhead and enabling compile-time type checking of the entire dependency graph
• Directed Acyclic Graph (DAG) — Wire builds a DAG of dependencies and detects cycles during analyze.go; understanding graph theory helps debug complex provider relationships
• Abstract Syntax Tree (AST) Walking — parse.go uses Go's ast package to traverse wire.go files and extract declarations; understanding AST traversal is essential to modify Wire's parsing logic
• Code Generation via Template or Builder — Wire generates wire_gen.go from analyzed dependencies; understanding how the tool constructs Go source (tokens, imports, function bodies) is critical to extend output
• Provider Functions and Constructor Injection — Wire injects dependencies by calling provider functions (NewFoo(dep1, dep2) -> Foo); this pattern aligns with Go idioms and avoids global state or reflection
• Type Unification and Constraint Resolution — analyze.go matches provider outputs to injector inputs by type; understanding type compatibility rules (concrete vs. interface, pointer vs. value) is needed to debug 'no provider' errors

• uber-go/dig — Alternative DI container for Go using reflection and runtime resolution; Wire chose compile-time generation instead for safety and performance
• go-kit/kit — Go microservices toolkit that uses Wire internally for service initialization in examples; common pairing for complex service graphs
• golang/go — Go language itself; Wire depends on golang.org/x/tools for AST parsing, so understanding Go's ast package is foundational
• google/go-cloud — Google's multi-cloud Go library that uses Wire extensively for provider initialization; largest real-world Wire usage reference
• grpc/grpc-go — gRPC Go implementation often paired with Wire for managing connection and service dependencies in server initialization

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive error case tests for internal/wire/parse.go and internal/wire/analyze.go

The repo has extensive testdata directories (BindInjectorArg, BindInterfaceWithValue, BuildTagsAllPackages, Chain, etc.) but lacks explicit unit tests for error handling paths in the core parsing and analysis logic. The parse.go and analyze.go files handle complex AST manipulation and dependency resolution—critical for correctness. Adding focused unit tests for malformed wire.go inputs, circular dependencies, type mismatches, and missing providers would catch regressions early and make the codebase more maintainable for future contributors.

• [ ] Create internal/wire/parse_test.go with tests for invalid wire.go syntax cases
• [ ] Create internal/wire/analyze_test.go with tests for circular dependency detection, missing provider detection, and type mismatch errors
• [ ] Add test cases covering edge cases like nil pointers, empty provider sets, and conflicting bindings
• [ ] Verify tests run via existing internal/runtests.sh workflow

Expand docs/guide.md with a 'Troubleshooting Common Errors' section

The repo is marked as no longer maintained, making documentation even more critical for users. The guide.md exists but lacks a dedicated troubleshooting section. By analyzing the testdata directories and error types in errors.go, a contributor could document common Wire errors (e.g., 'provider not found', 'ambiguous dependency', 'circular injection'), their root causes, and resolution steps. This reduces friction for new users and decreases GitHub issues.

• [ ] Review internal/wire/errors.go to identify all error types Wire can produce
• [ ] Add 'Troubleshooting' section to docs/guide.md with 5-7 common errors, examples, and solutions
• [ ] Cross-reference testdata test cases (e.g., internal/wire/testdata/) as examples in the guide
• [ ] Link troubleshooting section from README.md and docs/faq.md

Add integration test for wire CLI with Go modules and build tags combinations

The testdata directory shows tests exist for BuildTagsAllPackages and various binding scenarios, but there's no explicit integration test validating the cmd/wire/main.go CLI tool behavior with real go.mod projects using both build tags and cross-module dependencies simultaneously. This is a realistic user scenario and would catch CLI regressions. The test could be added to internal/runtests.sh and placed in a new testdata directory.

• [ ] Create internal/wire/testdata/ModuleWithBuildTags/ directory structure with a multi-module project using go.mod
• [ ] Define a wire.go with providers that span modules and use build tags (e.g., //go:build inject)
• [ ] Run cmd/wire/main.go against the test case and validate wire_gen.go output correctness
• [ ] Add test case to internal/runtests.sh to run as part of CI validation

• Add comprehensive error message tests in internal/wire/testdata/: create a testdata/BadCircularDependency/ case with want/program_out.txt showing human-readable cycle detection output; currently only a few error cases are tested
• Document the wire.go file naming convention and scan behavior in docs/guide.md: currently users discover via trial-and-error that wire.go is required; add an 'How Wire Finds Your Declarations' section with examples
• Add a testdata case for wire.Bind with interface{} types to internal/wire/testdata/BindInterfaceWithValue/ folder: the repo has BindInjectorArg and BindInterfaceWithValue directories but no test covering edge cases like binding concrete types to empty interface

The Wire project presents significant security concerns primarily due to its unmaintained status, which is explicitly stated in the README. The project no longer receives updates, security patches, or vulnerability fixes. While the codebase itself shows reasonable structure with proper separation of concerns (analysis, parsing, code generation), the lack of ongoing maintenance means any discovered vulnerabilities will not be addressed. The code generation approach introduces inherent complexity in AST manipulation that requires careful handling of edge cases. Dependencies are relatively minimal and well-known, but without active maintenance, the project cannot adapt to newly discovered vulnerabilities in its dependencies or its own logic. Organizations considering Wire should evaluate alternative, actively-maintained dependency injection solutions or implement enhanced internal security controls.

• High · Project No Longer Maintained — README.md. The README explicitly states 'This project is no longer maintained.' This means no security updates, bug fixes, or vulnerability patches will be provided. Using an unmaintained dependency injection tool in production systems poses significant security risks. Fix: Consider migrating to an actively maintained dependency injection solution. If Wire must be used, implement additional code review processes and security audits. Monitor for any disclosed vulnerabilities in Wire or its dependencies.
• Medium · Potential Code Generation Security Risks — internal/wire/analyze.go, internal/wire/parse.go, internal/wire/copyast.go. Wire is a code generation tool that auto-generates Go code. The security posture depends heavily on the robustness of the code generation logic. Files like 'internal/wire/analyze.go', 'internal/wire/parse.go', and 'internal/wire/copyast.go' are critical to security. Without active maintenance, any vulnerabilities in AST parsing or code analysis could persist. Fix: Conduct a thorough security audit of the code generation and AST manipulation logic. Ensure proper input validation and sanitization in the wire.go parsing mechanisms. Consider fuzzing the parser with malformed input.
• Medium · Indirect Dependency on golang.org/x/tools — go.mod - golang.org/x/tools v0.24.1. The project depends on 'golang.org/x/tools v0.24.1' which is part of the Go ecosystem's experimental packages. While generally secure, these packages may have longer vulnerability disclosure windows compared to stdlib. The tool uses this for AST manipulation and analysis. Fix: Regularly monitor security advisories for golang.org/x/tools. Keep the dependency updated to the latest patch version. Review the specific APIs being used from x/tools to ensure they're not deprecated or have known issues.
• Low · Test Data with Potentially Malicious Input Structures — internal/wire/testdata/. The extensive testdata directory (internal/wire/testdata/) contains test cases that may include edge cases, error conditions, and malformed structures. While test data itself is not a vulnerability, the handling of such data in the main codebase should be carefully validated. Fix: Ensure all test cases have corresponding validation and error handling in the production code. Review how the wire tool handles malformed wire.go files and invalid dependency configurations.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.