- Can I use PHP-DI in a Laravel application?
- Yes, mechanically. You can hand PHP-DI to Laravel as a Psr\Container\ContainerInterface implementation or bind it for consumers that type-hint PSR-11. That said, the fit inside a full Laravel app is poor because Illuminate\Container already provides autowiring, singletons and interface binding, and running both creates redundant container ownership. Use PHP-DI at the boundary, such as framework-agnostic packages, standalone services or test harnesses, rather than as a replacement for Laravel's container.
- How do I install PHP-DI with Composer, and which PHP versions are supported?
- Install it with composer require php-di/php-di. PHP-DI 7 requires PHP 8.0 or later and implements PSR-11, so it works with any framework or standalone PHP project. You do not need Laravel-specific packages or service providers to use it.
- How does PHP-DI compare with Laravel's built-in Illuminate container?
- Laravel's container offers autowiring, contextual binding, interface binding and singletons, and it is already PSR-11 compliant. PHP-DI adds an optional compiled container, attribute and PHP-config definitions, decorators and lazy proxies, but it is standalone and does not integrate with Laravel's lifecycle or facades out of the box. For a Laravel app the built-in container is almost always the simpler choice; PHP-DI is strongest when Illuminate packages are unwanted.
- How do I register PHP-DI as the PSR-11 container in Laravel?
- Register a binding for Psr\Container\ContainerInterface that returns your configured PHP-DI container instance, and have consumers type-hint that interface rather than Illuminate\Contracts\Container\Container. Keep Laravel's container as the default resolver for framework code and restrict PHP-DI to a defined namespace or package boundary to avoid ambiguity. No forking or patching is required because the API surface is small and PSR-11 is the contract.
- Does PHP-DI support autowiring and constructor injection?
- Yes. PHP-DI autowires constructor dependencies by reflection and supports explicit definitions via DI\create, DI\get, DI\factory, DI\env and PHP 8 attributes. Autowiring resolves at runtime, so union types, untyped scalars, variadics and constructor parameters without defaults fail during resolution rather than at build time. Add a container-warm or validation step in CI to catch those failures before production.
- What are the risks of using two DI containers in a Laravel app?
- The main risk is governance: two lifecycle owners create definition drift and an ambiguous answer to who resolves a given class. That ambiguity leads to onboarding friction and production incidents, and it buys little when Laravel already does autowiring and interface binding. Adopt an explicit rule such as PHP-DI governs namespace X and Laravel governs everything else, and keep the boundary enforced in code review.
- How does PHP-DI's compiled container affect deployment and caching?
- The compiled container is a deployment artifact and needs a writable, per-release cache directory. Stale caches after configuration changes produce silently wrong wiring, so each deploy must invalidate and rebuild consistently across nodes. Validate opcache preloading and read-only container filesystems explicitly, and include a container-warm step in CI or your release pipeline.
- Does PHP-DI support lazy injection, and should I use it in production?
- PHP-DI supports lazy injection through proxy generation, but that depends on a proxy-generation library whose upstream maintenance has historically been fragile. Treat lazy services as a supply-chain decision rather than a feature toggle, and decide who owns that dependency's lifecycle. If you do not genuinely need lazy dependencies, leave them disabled to reduce risk.
- How do I validate a PHP-DI container configuration before deploying?
- Build the container in a dedicated CI step and attempt to resolve every service before deploying. Because autowiring resolves by reflection at runtime, standard Laravel CI pipelines will not catch union types, untyped scalars, variadics or missing defaults. A container-warm or validate step catches constructibility failures early and also exercises the compiled-container cache path used in production.
- Is PHP-DI actively maintained, and what is the bus factor risk?
- PHP-DI is stable and the public surface is narrow, so fork risk is low, but the maintainer base is small and release cadence is low. Price in the possibility that nobody is home by isolating the container behind your own PSR-11 boundary so you can swap implementations. For most teams this is an acceptable trade-off because the code changes rarely and the contract is standard.