Di Annotations Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (and, more precisely, "adopt vs. wait for the platform"). This bundle is a case study in a capability the framework later absorbed. In 2012 it added annotation-driven service wiring to Symfony 2.x, which only supported XML/YAML/PHP container config; by 2017 Symfony had native autowiring, and by PHP 8 the whole mechanism had migrated to first-party attributes (#[Autowire]). The PM lesson: when evaluating a convenience layer, ask whether the upstream platform roadmap will commoditize it — and if so, price in its eventual obsolescence from day one rather than treating it as a durable dependency.
• Vendor/legacy modernization scoping. If loso/di-annotations-bundle appears in a dependency audit, that is a strong signal the service is pinned to Symfony 2.x and PHP 5.x. That single datapoint should trigger a migration epic, a support-cost estimate, and a freeze on new feature investment in that service until the DI layer is normalized. Use it as a triage marker, not as a component to fix.
• Laravel-specific decision: reject at intake. Despite being evaluated as a "Laravel/PHP package," this is a Symfony2 bundle with no Laravel bridge — no service provider, no adapter, and no equivalent to Symfony's bundle/compiler-pass layer in Illuminate\Container. Any Laravel team evaluating it should close the ticket as "solved by platform": Laravel's constructor autowiring, contextual binding (when()->needs()->give()), and (11.x+) #[Config]/#[Context] attributes already cover the stated need. The PM decision is to redirect the underlying request, not to source a replacement package.
• Roadmap sequencing for developer experience (DX). Annotation-based injection was a DX bet — less config boilerplate, wiring colocated with the class it affects. The lesson for roadmap planning is to prefer DX bets that align with the upstream framework's direction (autowiring, then attributes) rather than bets that fork it. A DX bet that fights the platform accumulates debt the moment the platform ships its own answer.
• Risk register entry. 14 stars, 0 dependents, Symfony 2.x EOL since 2016, doctrine/annotations deprecated ecosystem-wide. This belongs in the "unmaintained transitive dependency" bucket with an owner, a severity, and a remediation date — not in a scoping conversation about new work.
• Architecture standards / onboarding cost. Use it as a reference case in internal guidance: "prefer framework-native DI; do not introduce annotation/attribute-driven container magic that a new hire cannot trace in the container dump." Docblock annotations are invisible to IDEs and static analysis compared with PHP 8 attributes, which raises review ambiguity ("is this magic or a bug?") on every change.
• Make-vs-migrate prioritization. Where a team is weighing "keep patching the legacy app" against "rewrite the wiring," this bundle's presence is a concrete cost input on the keep-patching side: any continued use is effectively a permanent in-house fork, since upstream will never release again.
• Portfolio hygiene. Zero dependents means we cannot rely on any downstream community to surface bugs, security fixes, or compatibility patches. Adoption would make us the first and only production user of an abandoned artifact — a fact that should appear in any risk-adjusted estimate.

When to Consider This Package

Consider it only if all of the following are true:

• You are maintaining (not starting) a Symfony 2.x application that already depends on this bundle, with annotations baked into production classes.
• A full DI migration is out of scope for the current planning cycle, and the alternative is a riskier mid-quarter refactor of live service wiring.
• You have a named owner who can vendor and patch the code long-term — because it is effectively already unmaintained.
• The work is explicitly scoped as a reading reference (understanding how annotation-driven DI was historically implemented) rather than as a runtime dependency.

Look elsewhere — specifically, do not adopt — when:

• You are starting anything new. Symfony's native autowiring plus PHP attributes (Symfony 5.3+) covers this with first-party support, documentation, and a container you can actually debug (debug:container, lint:container).
• The target is Laravel. There is no integration path. Laravel's container is constructor-first and exposes no metadata/annotation extension point equivalent to Symfony's CompilerPass. Bolting this on would mean porting three subsystems (annotation reader, reflection layer writing into Illuminate\Container bindings, and lifecycle hooks Laravel doesn't provide) to replicate functionality the framework ships.
• Composer resolution must succeed. The symfony/symfony ~2.x pin, PHP 5.3-era constraints, and doctrine/annotations ~1.0 will hard-fail against a PHP 8.2/8.3 project. The only way to a green composer require is a fork whose constraints we own in perpetuity.
• You need maintained dependencies or a security response path. Zero dependents means no downstream pressure to fix bugs, no issue-history corpus, no escalation channel.
• You want static analyzability and low onboarding cost. Docblock annotations are opaque to IDEs and static analysis relative to PHP 8 attributes; the ramp-up tax lands on every new hire and every code review.
• The need is attribute-driven configuration on Laravel. Evaluate in order: constructor injection with interface bindings in a service provider → contextual binding → Laravel 11 attributes → a thin (~150-line) in-house attribute resolver only if 1–3 measurably fall short. All are owned, documented, and debuggable.

How to Pitch It (Stakeholders)

For executives. This is a small, unmaintained Symfony 2-era convenience library that let developers declare dependency injection via code annotations instead of XML/YAML config files. It has negligible adoption (14 stars, zero dependent packages), targets a framework version that went end-of-life in 2016, and depends on doctrine/annotations, which the PHP ecosystem has since replaced with native attributes. Modern Symfony and Laravel both ship this capability first-party, with better tooling and debuggability. Recommendation: no new investment. Treat it as a legacy marker — if it shows up in an audit, that is the trigger to schedule modernization of the dependent service, not to evaluate the package. The one-line ask: approve a small discovery ticket to inventory where annotation-based DI is used, so we can size the migration rather than guess at it.

For engineering. Do not add this to new work, and do not attempt a Laravel port. Symfony autowiring and PHP attributes supersede it and give you IDE support, static analysis, and a container you can dump and lint. Where it already exists in a legacy Symfony 2.x app, quarantine it: pin the version, document the affected classes, and fold its removal into the next framework-upgrade window (2.x → 5.4 LTS → 6.4/7.x) rather than a standalone refactor — the bundle should never be the reason an upgrade stalls. Expect removal to be low-effort per class but broad in surface area, since annotation wiring tends to spread across controllers and services. Two operational cautions if we do touch it: annotation parse errors can surface at cache-warm/deploy rather than in tests (exercise the reader in CI), and the mechanism is PHP-version-sensitive — an upgrade may fail open with silent mis-injection rather than a clear container error. Close the evaluation as "solved by platform" and redirect the underlying request to native autowiring; if the team genuinely needs attribute-style configuration beyond what the framework provides, scope a small in-house resolver in app/Support/Container/ that we can own, document, and deprecate on our own terms.