- How do I install league/container in a Laravel project?
- Install it with Composer by running composer require league/container; there are no external dependencies beyond PHP 8.3 or newer. In a Laravel application, avoid replacing the framework container app-wide. The package fits best inside a package or domain module that must also boot outside Laravel, not at the application root.
- Is league/container a drop-in replacement for Laravel's container?
- Architecturally it is a substitute for Illuminate Container, not a complement, and Laravel already ships a PSR-11-compliant container bound to Psr Container ContainerInterface. Running both app-wide creates two containers and two object graphs in one process. Use league/container at a module boundary instead of swapping out Laravel's container.
- Does league/container support auto-wiring out of the box?
- Auto-wiring is opt-in. You get it by delegating a ReflectionContainer, which resolves concrete classes via reflection. Without that delegate, every concrete class must be explicitly registered. Many teams assume auto-wiring is always on and are surprised when a class cannot be resolved.
- How do I make league/container fall back to Laravel for services it cannot resolve?
- Use the delegate method on the league container with an adapter that wraps Laravel's app() behind Psr Container ContainerInterface and implements has() with correct semantics for unbound concrete classes. Do not hand Laravel's container in raw, because its has() returns false for unbound concretes, so delegate resolution will not auto-wire them the way app() does. You can also bridge inward by passing leaf services such as config, logger, clock, or HTTP client as explicit bootstrap arguments.
- What PHP versions does league/container support?
- The current major supports PHP 8.3, 8.4, and 8.5. Applications still on PHP 8.1 or 8.2 must pin an older major of the package. That creates a second maintenance track and a future upgrade project, so confirm your PHP floor across all deploy targets before adopting it.
- How do I register services in league/container?
- Register services through AbstractServiceProvider subclasses and a composition root, using the container API for shared services, aliases, inflectors, and resolvable or literal arguments. Service providers keep registration explicit and testable. If you need convenience wiring for concrete classes, delegate a ReflectionContainer.
- When does league/container make sense in a Laravel codebase?
- The defensible fit is shared libraries, SDKs, or domain modules that must run in both Laravel and non-Laravel hosts such as CLI workers, queued consumers, or standalone tools. Depending on illuminate/container in those cases can be too heavy or creates a circular framework dependency. A secondary fit is an isolated module where you want a small, explicit container without auto-wiring magic.
- What are the risks of running league/container alongside Laravel's container?
- The main risk is a split-brain container: the same service registered in both graphs produces two singleton instances, divergent state, and confusing test behavior. Resolution failures also surface at get() time rather than at boot, so a misconfigured service can fail in production traffic instead of CI. Add a boot-time resolution smoke test and agree on ownership of the service-provider registration file.
- Why can't league/container resolve a class that Laravel's app() resolves fine?
- Laravel's has() returns false for unbound concrete classes, so a delegate fallback will report the entry as unresolvable instead of auto-wiring it the way app() does. The fix is to wrap app() in a PSR-11 adapter with correct has() semantics before delegating. Also check whether you remembered to delegate a ReflectionContainer for league/container's own auto-wiring.
- Is league/container actively maintained and tested?
- Yes. It is MIT licensed, tested with Pest and PHPStan at level 8 via composer test, and has an active release cadence. The main maintenance risk is the single primary maintainer, so factor that into long-term planning. Ignore the 0 dependents metadata flag and verify real-world usage on Packagist before using it in a build-vs-buy decision.