Weave Code
Di Laravel Package
aura/di
Aura.Di is a serializable dependency injection container for PHP 8+ supporting constructor and setter injection, interface and trait awareness, configuration inheritance, and PSR-11 compliance. It has no external implementation dependencies and installs via Composer as aura/di.
Dependency Injection System
Frequently asked questions about Di
- Can I replace Laravel's container with Aura.Di?
- No. Illuminate\Container\Container is the framework kernel, and facades, service providers, app()/resolve(), controller and middleware method injection, queued job and event hydration, Eloquent model resolution, and when()->needs()->give() contextual binding all depend on the roughly thirty methods of Illuminate\Contracts\Container\Container, while PSR-11 exposes only get() and has(). Swapping Aura.Di in for the Laravel container is a framework fork, not an integration task. Use Aura.Di alongside Laravel rather than in place of it.
- How do I install aura/di with Composer?
- Run composer require aura/di. The package is PSR-4 autoloadable under the Aura\Di\ namespace and requires PHP 8.0 or later; older PHP versions need 4.x (PHP 7.2+) or 3.x (PHP 5.5+). You can also download a release or clone the repository and map Aura\Di\ to the src/ directory manually.
- Is aura/di compatible with Laravel 10, 11 and 12?
- Constraint-wise yes: Aura.Di requires PHP 8.0+ and psr/container ^2.0, both satisfiable alongside Laravel 10, 11 and 12. What it cannot do is serve as the application container, because Laravel's kernel is bound to Illuminate\Contracts\Container\Container. Compatibility here means running side by side inside your app, not replacing anything.
- How do I use Aura.Di inside a Laravel application?
- Use the side-by-side approach: let Aura.Di own a subsystem's object graph, then register the resulting instances (or a PSR-11 delegate) into Illuminate\Container via instance() or bind() from a thin Laravel service provider. This has a low risk profile and a contained blast radius. If a package only needs PSR-11, expose Aura.Di as the Psr\Container\ContainerInterface implementation and have Laravel satisfy it through a delegate provider, verifying that no consumer calls non-PSR-11 methods.
- Why is my Aura.Di container locked after the first get()?
- Aura.Di auto-locks the container after the first get() or newInstance() call, so configuration cannot be mutated once resolution begins. This behavior is documented and intentional, but developers trained on Laravel's mutable, always-available container hit it during onboarding. If any part of your code needs to mutate the container after resolution, auto-locking is disqualifying and you should not use Aura.Di for that subsystem.
- Why does serializing or compiling my Aura.Di container fail?
- Closures in configuration break serialization, so keep your config free of them if you plan to serialize or pre-compile the container. Build artifacts must also be invalidated on every deploy, because a stale compiled container is a silent and hard-to-diagnose failure class. The serializable container is Aura.Di's distinguishing feature, but it demands disciplined cache handling.
- Is Aura.Di PSR-11 compliant?
- Yes, Aura.Di attempts to comply with PSR-11 and also follows PSR-1, PSR-2 and PSR-4, so it can be injected wherever a Psr\Container\ContainerInterface is expected. The caveat is that PSR-11 only guarantees get() and has(); confirm that no consumer depends on richer container methods. Laravel can satisfy the PSR-11 interface through a delegate provider.
- How does Aura.Di compare to Laravel's service container?
- Laravel's container is a mutable, always-available kernel component with contextual binding, tagging, extending, rebinding hooks and about thirty public methods. Aura.Di is a standalone, zero-implementation-dependency container offering constructor and setter injection, interface and trait awareness, configuration inheritance, lazy services, PSR-11 compliance, and a serializable/compilable container. Architecturally it is the opposite philosophy, so pick it when you need a portable container inside a package or bounded context, not when you need framework features.
- Do I need the bin/auradi scan and #[Blueprint] compiler?
- Often you do not. Plain PHP configuration classes may be enough and would eliminate most of the compile-path risk, including classmap correctness bugs and stale build artifacts. The runtime container is battle-tested, but the scan and #[Blueprint] compilation toolchain is newer and still stabilizing after many 5.0.x patch releases. Also check whether composer/class-map-generator is install-time or build-only so it does not leak into your production dependency tree.
- How do I run the Aura.Di test suite, and what are the maintenance risks?
- Run composer install, then composer test at the package root; Composer must be available on the command line. On maintenance, the runtime container is mature, but the 5.0.x line has seen many patch releases fixing classmap issues, and attribute-driven configuration using #[Service], #[Instance] and #[Value] is invisible to IDEs and to Laravel tooling like Telescope and artisan about. If long-term continuity matters, plan who owns upgrade and fork risk should the Aura organization go quiet.
Weaver
How can I help you explore Laravel packages today?