Container Wrapper Bundle Laravel Package

Product Decisions This Supports

• Dependency policy / framework fit. This is a Symfony bundle, not a Laravel package — evaluating it forces an explicit decision about whether our dependency approval process is scoped per-framework. It is a useful test case for codifying "no archived packages in the critical path."
• Build vs. buy vs. borrow-the-idea. With a 2015 last release, archived status, and zero dependents, "buy" is off the table. The real decision is whether the underlying pattern is worth ~1 day of in-house implementation.
• DI governance standards. Whether we allow ContainerInterface/Container injection into application services at all, and what the code-review rule is (fail CI vs. warn).
• Legacy migration sequencing. If a monolith injects the container everywhere, a thin observable wrapper is a credible intermediate step: it logs which services are actually pulled, giving us a data-driven refactor backlog instead of a guess.
• Technical debt story for the roadmap. Not a feature enabler — at most an internal tooling/lint item, sized in days, not a quarter.
• Not supported: no user-facing capability, no revenue path, no integration surface. Do not let this appear on a roadmap as a feature dependency.

When to Consider This Package

• As a runtime dependency: essentially never. Archived, deprecated, last release 2015-10-26, zero dependents, no security patching, and incompatible with supported Symfony/PHP versions. Installing it puts unmaintained code in the request path.
• Consider the pattern only when: you have a large legacy codebase with pervasive container injection and need a measured stepping stone. The wrapper's value was making hidden service-locator usage visible and countable so teams can prioritize which services to convert to constructor injection.
• Look elsewhere when you are on Laravel (our case): use contextual binding, service providers, and interfaces bound in providers; reserve Illuminate\Contracts\Container\Container for framework-level code; if you genuinely need lazy access, write a small typed service locator you own — do not resurrect a Symfony bundle.
• Look elsewhere on Symfony: ServiceLocatorTagPass, service subscribers, #[AutowireLocator], and the built-in container linting cover the same ground natively.
• If the only goal is telemetry ("which services are actually used?"), a custom decorator plus Deptrac/PHPStan rules is cheaper and maintainable; skip the package entirely.

How to Pitch It (Stakeholders)

Bottom line: decline as a dependency; adopt the idea as an internal guardrail.

To executives: We evaluated a candidate library and are recommending against it. It is a 2015-era bundle, formally deprecated and archived, with no downstream users and no security maintenance — zero cost avoided by declining, real risk avoided. The one durable idea behind it, making "inject everything" visible so it can be refactored, can be reproduced internally in about a day if we have that problem. No budget impact, no roadmap change; this is a governance win, not a feature.

To engineering: The package solved a real problem — teams injecting the whole container because explicit dependencies were painful — by wrapping it so usage could be tracked and ratcheted down. That problem is worth acknowledging, but the artifact is dead: Symfony now ships service locators and #[AutowireLocator], and on Laravel we have contextual binding and providers. Proposal: reject the dependency, add Deptrac/PHPStan rules that fail CI when the container is injected into domain services, and if a legacy module needs a transition period, ship a small observable wrapper with a written deprecation date. Measure adoption by counting container injections per module over time, not by whether the package is installed.