Dependency Injection Extra Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin convenience layer over symfony/dependency-injection: it ships CompilerPassInterface implementations (documented: AddTaggedCompilerPass) that wire tagged services into a registry via a method call, optionally forwarding tag attributes.
• That layer belongs to the Symfony container compilation model: Bundle::build(), ContainerBuilder::addCompilerPass(), container dump/cache warmup. Laravel uses Illuminate\Container as its runtime container and does not compile a Symfony ContainerBuilder. This component is therefore not in the Laravel request/DI path at all.
• Laravel already provides the functional equivalent natively: $this->app->tag([...], 'my_provider') plus $this->app->tagged('my_provider'), which returns a lazy RewindableGenerator over the tagged bindings. Priority ordering and attribute-style metadata can be layered on with a few lines of registry code or contextual binding. The package solves a problem Laravel has already solved.
• The only defensible fit is a shared PHP library that uses Symfony DI compilation and is consumed by both Symfony and Laravel hosts (e.g., a plugin/module registry compiled once into a dumped container). In that scenario the package is a convenience, not a capability.

Integration feasibility

• Technically trivial to install if a symfony/dependency-injection instance already exists in the tree; near-zero code surface, MIT license, no service providers, no config, no runtime hooks.
• Practically low value: introducing a second container abstraction into a Laravel codebase is a durable maintenance tax for a feature the framework ships.
• Deprecation is the headline finding: the README explicitly redirects to paysera/lib-dependency-injection as a superset. Adopting a library that its own author has superseded is a decision that must be justified with a specific reason, not convenience.

Technical risk

• Abandonment: last release 2020-02-02; no commits expected. Any incompatibility (PHP 8.x engine changes, Symfony constraint widening) becomes our patch.
• Version friction: the Composer constraint almost certainly pins Symfony 3.4/4/5-era ranges. Installing alongside Symfony 6/7 will likely require a fork or replace; the compiler-pass API itself has been stable, so the fix is usually constraint surgery plus a test run — but that is unowned work.
• Zero dependents / 6 stars (opportunity score 35.8, score 0.75): essentially no community validation, no issue-tracker signal, no third-party compatibility evidence. Bus-factor of one, and that one has moved on.
• Low security surface: compile-time only, no I/O, no network, no deserialization. Risk is correctness and drift, not exploitation.
• Behavioral coupling: the registry method signature is dictated by tag-attribute order, so refactors are silently breaking rather than type-checked.

Key questions

1. Is there an actual symfony/dependency-injection ContainerBuilder in the target application, or is this being evaluated for a Laravel app that has none?
2. Does the requirement reduce to "collect tagged implementations and inject them as an ordered list"? If yes, app->tagged() closes it and the evaluation ends.
3. Who owns the fork if we need Symfony 6/7 or PHP 8.3+ support, and is that cheaper than 50 lines of in-house compiler pass or 10 lines of service-provider tagging?
4. Is paysera/lib-dependency-injection being considered in the same evaluation, and why not — it is the author's stated successor with more features?
5. Do we need tag-attribute forwarding (name, theme, priority) specifically, and does paysera/lib cover it?
6. What is the exit cost if the library is removed in 12 months — is it isolated to one bundle build method?

Integration Approach

Stack fit

• Laravel-first stack: poor fit, recommend against. Use Illuminate\Container tagging ($this->app->tag, $this->app->tagged) inside a service provider; implement ordering with a small Registry class that sorts by priority. This keeps one container, one mental model, and a maintained dependency.
• Hybrid stack (Laravel app hosting a shared library that also targets Symfony): acceptable, provided the Symfony ContainerBuilder is confined to the library's composition root and does not leak into framework bootstrap.
• Symfony-first stack: the package is redundant anyway — use _instanceof autoconfiguration plus a small compiler pass, or paysera/lib-dependency-injection.

Migration path

• If already adopted: do not delete-and-rewrite. Extract the registry contract (addProvider(ProviderInterface, string $name, string $theme)) into our own interface first, so both the compiler pass and a Laravel tagging implementation can satisfy it.
• Then either (a) swap to paysera/lib-dependency-injection if still on Symfony DI, or (b) replace the compiler pass with a service provider using tagged(). Both are contained changes if the registry contract is stable.
• If adopting fresh: start at paysera/lib-dependency-injection — the deprecation notice is an explicit, unambiguous signal. Do not onboard a 2020 package with zero dependents.
• Vendoring/forking maba/dependency-injection-extra internally is a valid escape hatch for legacy Symfony 4/5 apps, but treat it as a freeze, not a foundation: widen constraints, add PHP 8 CI, tag an internal version, and record it on the deprecation watchlist.

Compatibility

• Verify the Composer constraint against the current PHP and Symfony versions before anything else; this is the single most likely blocker.
• Check the full pass inventory (README excerpt documents only AddTaggedCompilerPass) — do not assume additional passes exist.
• Compiler passes interact with container dumping and caching: confirm behavior under container:cache:clear, and confirm tagged services defined in other bundles are visible at compile time.
• No Laravel-specific compatibility surface exists (no service provider, no facade, no config), so there is nothing to shim on the Laravel side — which is itself the argument.

Sequencing

1. Confirm whether a Symfony ContainerBuilder exists in the target system. If no → close evaluation, implement native Laravel tagging.
2. If yes → evaluate paysera/lib-dependency-injection first as the primary candidate; treat this package as the fallback only if the successor is also unusable.
3. Spike: one registry, two tagged implementations, one optional tag attribute, verified through container compilation and cache warmup. Timebox to a day.
4. Decide fork-vs-native-vs-successor; document the decision and the rationale for adopting a deprecated dependency.
5. Add a recurring review item: any deprecated dependency gets re-evaluated at each major PHP/Symfony upgrade.

Operational Impact

Maintenance

• Effectively unmaintained upstream. Assume zero bug fixes, zero PHP/Symfony version bumps, zero security advisories. Any required change is ours.
• Small footprint (~1 class plus tests) means the fork burden is genuinely low — but it is still permanent, unglamorous, undocumented ownership.
• Deprecation compounds: every future framework upgrade forces a "does the abandoned pass still work?" check that no one will remember to schedule.

Support

• Self-support only. No vendor, no active maintainer, no meaningful issue history to mine. Internal documentation must capture the tag-attribute-to-method-argument contract, because that contract is implicit and unenforced.
• Onboarding cost is near zero (a few hours to read the pass), but the implicit cost is that new engineers will not know this layer exists — it is invisible wiring with no Laravel-idiomatic footprint.

Scaling

• Neutral. Compilation-time only, no runtime overhead, no per-request cost, no I/O. Tagged-service iteration is lazy in the Symfony generator, so large tagged sets are fine.
• The scaling concern is organizational, not technical: the more services wired this way, the more the registry method signature becomes an untyped choke point, and the harder a future migration becomes.

Failure modes

• Silent mis-wiring: required tag attributes missing → compile-time error at best, wrong registry key at worst; no static analysis catches the positional argument contract.
• Order dependence: registries keyed by iteration order behave nondeterministically across environments if service definition order differs; sorting must be explicit.
• Constraint lockout: a future framework/PHP upgrade makes the package uninstallable and blocks the whole upgrade train until someone forked it — this is the highest-probability, highest-cost failure.
• Stale container: cached/dumped containers in deploy artifacts retain old wiring after a tag change; requires disciplined cache clearing in the pipeline.
• Orphaned abstraction: a second container model lives in the app, and new engineers wire services the Laravel way, producing two registration idioms and inconsistent behavior.

Ramp-up

• Reading and understanding: under a day. The API is one class and one usage snippet.
• Understanding why it is there, who owns it, and what replaces it: the real cost, and it is entirely avoidable.
• Recommendation to the delivery team: do not adopt. The capability is native to Laravel, the package is deprecated by its own author in favor of a superset, it has no community validation, and it has not shipped since 2020. Score 0.75 with an opportunity score of 35.8 is consistent with that conclusion — this is a convenience shim for a framework we are not building on. If a Symfony-DI composition root is genuinely required, evaluate paysera/lib-dependency-injection and document the exception.