Container Laravel Package

Product Decisions This Supports

• Build vs. buy for dependency injection: Adopt rather than build. A custom DI container is undifferentiated infrastructure; illuminate/container is mature, MIT-licensed, and already battle-tested across the Laravel ecosystem. This frees engineering capacity for product work.
• Architecture and modularity: Interface-to-implementation bindings let teams commit to modular design (services, repositories, gateways) without locking in concrete implementations. This de-risks decisions like "which payment provider / storage backend / mail service" by making swaps a configuration change rather than a refactor.
• Extensibility and roadmap sequencing: Tagging and tagged resolution support plugin-style architectures, formatter/list registries, and event listener sets. Useful when the roadmap includes marketplace integrations, add-on modules, or customer-specific extensions.
• Testability as a product-quality lever: Container bindings make it cheap to substitute mocks and fakes in tests. This supports a decision to invest in TDD/CI quality gates rather than manual QA cycles.
• Standardization and hiring: If the org is considering Laravel as a standard, this package is included by default — no procurement, licensing, or onboarding cost. It also aligns with the largest available PHP talent pool.
• Platform/ops decisions: The static global container instance and runtime-only circular dependency detection are relevant to decisions about queue workers, Horizon, Octane, serverless, and multi-tenant deployments. Treat these as architecture constraints to design around, not blockers.
• Upgrade timing: PHP 8.3+ requirement is a real roadmap input for legacy environments; factor it into platform modernization planning.

PM caution on the data: "0 dependents" reflects the subtree-split packaging of laravel/framework, not actual adoption. Do not use it as a signal of maturity or community support in prioritization discussions.

When to Consider This Package

Adopt when:

• You are building or maintaining a Laravel application — it is bundled, zero setup, and the default resolution path for controllers, jobs, events, and commands.
• You need PSR-11 compliance plus Laravel-specific capabilities: contextual binding (when()->needs()->give()), tagging, method injection via call(), and post-resolution decoration via extend().
• You want plugin/extension points or environment-specific bindings without bespoke infrastructure.
• Your team already holds Laravel skills and you value ecosystem compatibility (first- and third-party packages assume this container).

Look elsewhere or proceed with caution when:

• The project is non-Laravel and must stay dependency-light — smaller PSR-11 containers (e.g., PHP-DI) may be a better fit.
• You require strict PSR-11 portability: tag(), extend(), build(), and contextual bindings will not work in other containers. Do not let product code depend on them if container-independence is a stated goal.
• You are running a hybrid stack alongside Symfony's DI or another static-resolution container — conflicts and dual-resolution ambiguity are likely.
• You operate in constrained environments or on PHP < 8.3.
• The application is small enough that manual constructor wiring is clearer than container indirection.
• Circular dependencies are a recurring symptom — that usually signals an architectural problem the container cannot solve for you.

How to Pitch It (Stakeholders)

Executives: This is the dependency injection engine already inside every Laravel application — proven, MIT-licensed, and maintained by the framework team. Adopting it means we do not fund or maintain custom plumbing, we can swap vendors (payments, storage, messaging) without rewriting features, and we inherit a large hiring pool. The main decision it asks of us is a platform commitment to PHP 8.3+ and the Laravel ecosystem; the return is lower total cost of ownership and faster, more predictable delivery.

Engineering: Zero setup in Laravel; composer require standalone. Use interface bindings for testability, contextual binding for per-consumer implementations, tagging for plugin registries, call() for method injection, and extend() for cross-cutting decoration. Three guardrails: avoid mutating the global container instance in long-running workers, keep constructors free of resolve-time cycles or defer with make(), and remember PSR-11 compatibility does not imply feature parity — Laravel-specific APIs are not portable. Design for local container instances and explicit dependencies, and this becomes invisible infrastructure rather than a source of production surprises.