Di Laravel Package

Product Decisions This Supports

• Build vs. buy for container plumbing. If a roadmap item requires dependency injection outside of Laravel — an extracted shared library, a CLI tool, a worker, or a package meant to run on Symfony/Slim/plain PHP — this package is a candidate to evaluate against writing a container in-house. It is a PSR-11 implementation, so the interface contract is standard even if the implementation is not.
• Framework-decoupling / exit-risk planning. Adopting PSR-11 interfaces (rather than Illuminate\Container directly) in library code is a real architectural decision. This package makes that decision concrete and testable at low cost, and informs whether "framework-agnostic core" is a viable roadmap theme or just aspirational.
• Interoperability commitments. If the product needs to consume or ship third-party packages that type-hint Psr\Container\ContainerInterface, this is one way to satisfy that requirement without pulling in a heavier container.
• Distribution strategy for a package or SDK. For a public SDK, dependency weight is a product concern. A small, single-purpose PSR-11 container can be pitched as a minimal-dependency story — but it must be weighed against the support burden of an obscure dependency in a customer-facing artifact.
• What it does not decide: in a Laravel application, the container question is already answered. Illuminate\Container provides autowiring, contextual binding, tagging, decorators, and lifecycle hooks, and is maintained by the framework team. This package is not a substitute, and treating it as one would be a net-negative decision.

When to Consider This Package

Consider it only when all of the following hold:

• The consuming code lives outside a Laravel application context (standalone library, microservice, CLI, or multi-framework package).
• The requirement is genuinely PSR-11-only — get() and has() — with no need for autowiring, contextual binding, tagged collections, service providers, or compile-time optimization.
• The team has done a maintenance/liveness review and is comfortable with the risk: ~20 stars, an unresolved repository link, and an effectively single-maintainer project.
• The alternative "write ~150 lines ourselves" has been priced honestly, including tests and long-term ownership.

Look elsewhere when:

• You are building on Laravel. Use the framework container. Full stop.
• You need autowiring or configuration-driven wiring. Use php-di/php-di, Symfony's DI component, or Laravel's container — all have large communities, documentation, and active release cadence.
• You need performance at scale. Compiled containers (Symfony DI, PHP-DI with compilation) are the mature answer; a reflection-based runtime container will show up in profiles on hot paths.
• Procurement, security review, or SLA obligations apply. A dependency with ~20 stars and no clear upstream is a supply-chain and abandonment risk that will cost more in review cycles than it saves.
• You need a supported, documented API surface for a team that isn't the original author.

Net read on the scores: opportunity: 0.38 with score: 0.55 is consistent with "legitimate but commoditized." PSR-11 containers are a solved problem with several well-maintained incumbents, so the upside is bounded and the differentiation is near zero.

How to Pitch It (Stakeholders)

To executives (one line): A small, standards-compliant dependency injection library that could let parts of our code run outside Laravel — but it's a low-maturity project, so I recommend a timeboxed spike rather than an adoption commitment.

To engineering: This is a PSR-11 container — the interface is standard, the implementation is not battle-tested. It is only relevant for code that must live outside the Laravel runtime, and only if we're confident we'll never need autowiring, contextual binding, or tagged services. Before we adopt, we should (a) confirm the upstream repo and maintenance status, (b) spend a day proving the "framework-agnostic core" hypothesis with it, and (c) benchmark it against php-di/php-di and Symfony DI on the same spike. If the spike succeeds, the more defensible move is likely to implement PSR-11 against a maintained container — the standard is the asset, not this package.

Recommendation: Hold. Do not add to the dependency manifest today. Fund a short, scoped evaluation only if a roadmap item actually requires out-of-framework DI; otherwise revisit when that need becomes real.