Product Decisions This Supports
- Build vs. buy (verdict: build — but "build" here means "use the framework's native container," not this package). The only capability on offer is autowiring for a Symfony DI container. Symfony shipped autowiring natively in 2.8 (2015) and made it the default developer experience from 3.3/4.0 onward. This package's last release was 2016-02-10, roughly the same window. We would be adopting a third-party shim for a problem the platform solved upstream seven-plus years ago.
- Roadmap: close the ticket, don't schedule it. 12 stars, 0 dependents, archived, single-maintainer provenance. A dependency with zero downstream consumers is a signal that no production team validated it; we would be the first, on an unmaintained codebase.
- Portfolio fit: it isn't a Laravel package. This is a Symfony bundle. If the evaluation was triggered by a Laravel requirement, the answer is "not applicable" — Laravel's container already resolves concrete classes and constructor dependencies without registration, so there is no gap to fill and no adapter worth writing.
- Legitimate use case is narrow and historical: a Symfony ≤2.7 application that is frozen on an old LTS, cannot upgrade this cycle, and needs constructor autowiring to reduce service-definition boilerplate. Even then, the better product decision is usually to register services explicitly or scope an upgrade, because the shim's value expires the moment the upgrade lands.
- Reference value only: useful as an artifact for understanding what pre-native autowiring looked like, and as a comparison point if we ever debate extending a container ourselves instead of adopting framework features.
When to Consider This Package
Consider it only when all of the following hold:
- The codebase is Symfony 2.x (pre-2.8) and pinned there for a documented, time-boxed reason.
- An upgrade path exists and is funded; the shim is a stopgap measured in weeks, not quarters.
- The team has accepted ownership of a forked, archived dependency — including patching it themselves — and has recorded that in the risk register.
- The alternative (explicit service definitions, or a compiler-pass-based workaround) has been costed and is genuinely more expensive than carrying the fork.
Look elsewhere — or rather, do nothing — when any of these are true:
- The stack is Laravel. Different framework, different container, no integration point.
- The stack is Symfony 2.8+. Native autowiring supersedes it entirely; adding this package adds a dependency and removes nothing.
- This is a new build. Never start a greenfield service on an archived dependency.
- Security, compliance, or SLA obligations apply. MIT licensing is permissive and fine, but "archived" means no CVE response, no PHP-version compatibility work, and no maintainer to escalate to. That is an unowned risk, not a cheap dependency.
- We need anything beyond basic constructor wiring — tagging, decoration, conditional services, attribute-based configuration. The package predates all of it.
How to Pitch It (Stakeholders)
To executives (one line): We evaluated kutny/autowiring-bundle and recommend against adoption — it duplicates a capability the framework now provides for free, it has been archived since 2016 with no maintainers, and it has zero downstream users, so adopting it would add unowned maintenance and security risk in exchange for no functional gain. Cost of the decision: zero. We continue on framework-native dependency injection.
To engineering (one paragraph): This is a Symfony bundle, not a Laravel package, so it does not apply to our Laravel services at all — Laravel's container already autowires. For any Symfony service, native autowiring has been available since 2.8 and is the default from 4.0, which makes this package redundant. It is MIT-licensed, last released 2016-02-10, archived, 12 stars, 0 dependents, and scored 0.175 on our evaluation — that combination means no upstream fixes, no PHP 8 compatibility, and no one to page. If a legacy Symfony 2.7 app genuinely needs autowiring before it can be upgraded, treat that as a scoped fork with a named owner and an expiry date tied to the upgrade, not as a dependency we add to composer.json.