Dependency Injection Extra Laravel Package

Product Decisions This Supports

• Build vs. buy for DI boilerplate. The package solves one narrow problem: registering tagged services into a registry without hand-writing a CompilerPass class for every integration. That's roughly 20–30 lines of code per case, so the real decision this informs is "do we take a third-party micro-dependency to save boilerplate, or do we own a small internal helper?" For a package this size, owning it is usually cheaper than a dependency.
• Extension-point design for our own packages. If we ship a bundle or package that exposes a registry/provider collection, the pattern here (tag + optional tag attributes + a single mutator method) is a good template for how integrators register into us. It lowers integration friction and documents intent in config rather than in code.
• Framework-strategy scoping. This is Symfony Dependency Injection tooling. In a Laravel-first codebase the equivalent is container tagging ($this->app->tag(), resolve/tagged()), so the package is only relevant to decisions where we ship Symfony bundles or maintain dual-framework packages. It should not leak into the Laravel roadmap as a container strategy.
• Dependency-risk triage. The README opens with a deprecation pointing to paysera/lib-dependency-injection. That converts the roadmap item from "adopt" into "evaluate the successor" — a decision this package makes for us rather than one it supports.

When to Consider This Package

Adopt only in a narrow legacy scenario: an existing Symfony 3/4-era application already has a bundle with several near-identical compiler passes, is pinned to older PHP/Symfony versions, and the team wants a shortcut for the next one without an internal abstraction.

Look elsewhere — or write the ~25 lines yourself — if any of these hold:

• Greenfield work. Deprecated upstream, last release February 2020, 6 stars, 0 dependents. There is no compatibility signal for PHP 8 or Symfony 5/6, no ecosystem validation, and no support path. Starting new work on it is indefensible.
• Laravel-only stack. Use the framework's own tagging; the compiler-pass model doesn't map.
• Anything with a maintenance horizon. Single-maintainer, low-visibility utility with an already-declared successor means the migration cost is guaranteed and the benefit is near zero.
• You need more than tagged registration. The package contains exactly one compiler pass; the moment requirements grow, you're back to writing custom passes anyway.

If the pattern is genuinely valuable, the correct move is to evaluate paysera/lib-dependency-injection as the maintained option, or vendor a small internal AddTaggedCompilerPass we control.

How to Pitch It (Stakeholders)

For executives: This is a tiny, single-purpose utility that saves a developer a few dozen lines of setup code. It is officially deprecated by its author, has no adoption to speak of, and hasn't shipped since early 2020. Recommendation: no investment, no adoption, no procurement — the cost of taking it on exceeds the cost of writing the equivalent ourselves. If we're already using it somewhere, treat it as technical debt with a low-cost exit.

For engineering: The idea is worth copying; the dependency is not. Declarative tagged-service registration via a reusable compiler pass is a reasonable convention for our own packages, and it's small enough to own internally. Do not add maba/dependency-injection-extra to new work — it's deprecated in favor of paysera/lib-dependency-injection, untested against current PHP/Symfony, and effectively unmaintained. Audit existing usages and plan a migration, replacing with either the successor or an in-house pass.