Autowiring Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and arguably a category error. kutny/autowiring-bundle is a Symfony bundle, not a Laravel package. It hooks into Symfony's CompilerPass / ContainerBuilder pipeline to add reflection-based constructor injection. Laravel has no bundle concept, no compiler passes, and no shared DI internals with Symfony — Illuminate\Container is an independent PSR-11 implementation with its own reflection-based auto-resolution. Laravel has resolved typed constructor dependencies automatically since 5.x, so the capability this package provides is already native on the target stack.

Integration feasibility — not feasible at acceptable cost. Making this work under Laravel would mean reimplementing its compiler pass against Illuminate\Container, which is effectively writing a new package whose only inherited asset is a 2016 design. There is no adapter layer, no service provider, and no PSR-11 interoperability (the package predates PSR-11's 2018 ratification). A one-day spike is sufficient to confirm incompatibility; anything beyond that is sunk cost.

Technical risk — high and non-mitigable.

• Archived upstream: no security response path, no CVE monitoring, no patch release if a vulnerability is disclosed.
• Last release 2016-02-10, with PHP 5.x/7.0-era version constraints that will not satisfy a modern PHP 8.x platform requirement without a fork.
• 12 stars and 0 dependents: no community to inherit maintenance, no downstream usage to validate it in production, no ecosystem pressure to keep it working.
• Quality score of 0.175 is consistent with an abandoned, single-author, low-adoption artifact.
• Supply-chain exposure: abandoned packages are a known target for name-squatting and unmaintained-fork takeovers; any fork we adopt carries unverifiable provenance.

Key questions for the requesting team.

1. What problem are we solving that Laravel's container does not already solve? If the answer is "explicit wiring," the tool is contextual binding or a service provider, not this.
2. Is the actual target a legacy Symfony application (2.x/3.x pre-3.3)? If so, say so — the recommendation changes, but only slightly.
3. Who owns the fork, and what is the budget for permanently owning a DI compiler pass we do not need?
4. Does our dependency policy require a maintained upstream, SBOM coverage, and CVE response? If yes, this fails on policy alone.
5. Are we evaluating because of an existing composer.lock transitive dependency? If so, the work is removal, not integration.

Integration Approach

Stack fit — none on Laravel. The package assumes Symfony\Component\HttpKernel\Bundle\Bundle and the Symfony DI component. Neither is present in a standard Laravel install. The only environment where it fits is a Symfony application pinned below 3.3.

Migration path — recommend rejection, with a documented alternative. For any team that genuinely needs the behavior:

• On Laravel: rely on the container's built-in typed constructor resolution, bind interfaces in a service provider, and use contextual binding where implementations differ per consumer.
• On Symfony: use native autowiring (autowire: true in services.yaml), available since Symfony 3.3 (2017) — this package's entire reason for existing was upstreamed nearly a decade ago.
• On framework-agnostic codebases: PHP-DI is maintained and PSR-11 compliant.

Compatibility. No Laravel service provider, no extra.laravel manifest, no PSR-11 container, no PHP 8 support. Expect a hard composer require failure on the platform constraint before any code-level incompatibility surfaces.

Sequencing. Do not place this on a roadmap. The only sequence is: (1) confirm the request's underlying need in a 30-minute conversation; (2) if unresolved, time-box a spike to one day to produce a written incompatibility finding; (3) record the decision as an ADR so the same request does not recur; (4) if it exists as a transitive dependency, schedule removal and pin/replace the parent package.

Operational Impact

Maintenance. Zero upstream maintenance. Adoption means we own the code permanently, including the compiler pass, the PHP-version compatibility work, and the security posture. That is a recurring cost for a capability the framework provides free.

Support. No maintainer, no vendor, no release cadence, no issue triage, no security advisory channel. Documentation is a README. Internal engineers would be the sole support tier for a component they did not design.

Scaling. Runtime performance is a non-issue: DI wiring resolves at container compile time, so throughput impact is negligible either way. The scaling concern is organizational — every engineer who touches this must learn Symfony DI internals to debug it, and that knowledge has no reuse on a Laravel codebase.

Failure modes.

• Container compilation failures from unresolvable reflection types, surfacing as opaque boot-time errors rather than clear configuration errors.
• Fatal errors or deprecation floods on PHP minor-version upgrades, with no upstream fix path.
• Silent behavioral drift if a transitive version constraint is loosened by another package's update.
• Security exposure with no disclosure-to-patch loop — the worst failure mode, because it is invisible until exploited.

Ramp-up. Near-zero engineering value and non-trivial cognitive cost. The package teaches an approach to DI that the target framework superseded, so onboarding effort produces no transferable capability.

Recommendation. Reject. This is an archived, single-author, zero-adoption Symfony bundle whose function was absorbed into Symfony's core in 2017 and was never applicable to Laravel. The correct TPM action is to close the request with the alternatives above and, if the package is already present transitively, open a removal ticket rather than an integration ticket.