Di Laravel Package

Technical Evaluation

Architecture fit. Aura.Di is a standalone, PSR-11-compliant container with constructor/setter injection, interface and trait awareness, config inheritance, lazy services, and — its distinguishing feature — a serializable/compilable container. Architecturally it is the opposite of Laravel's container philosophy. Illuminate\Container\Container is not a swappable component; it is the framework kernel. Facades, service providers, app()/resolve(), controller and middleware method injection, queued job and event listener hydration, Eloquent model resolution, and the when()->needs()->give() contextual binding API all depend on Illuminate\Contracts\Container\Container, which exposes roughly thirty methods (bind, singleton, scoped, instance, tag/tagged, extend, when, call, makeWith, factory, resolved, beforeResolving/afterResolving, rebinding, forgetInstance(s), flush, …). PSR-11 gives you only get() and has(). Substituting Aura.Di for the Laravel container is therefore not an integration task; it is a framework fork. Any evaluation that frames this as "replace Laravel's container" should be rejected at triage.

Where Aura.Di does fit: as the internal container of a framework-agnostic package or bounded context that must run identically inside Laravel, inside a standalone CLI worker, and inside a non-Laravel service in the same monorepo. There it is a reasonable, mature, zero-dependency choice.

Integration feasibility. Feasible in three narrow shapes, in ascending cost:

1. Side-by-side — Aura.Di owns a subsystem's object graph; a thin Laravel service provider registers the resulting instances (or a PSR-11 delegate) into Illuminate\Container via instance()/bind(). Low risk, contained blast radius.
2. PSR-11 bridge — expose Aura as the Psr\Container\ContainerInterface implementation injected into a package, letting Laravel satisfy it through a delegate provider. Moderate risk; must verify no consumer calls non-PSR-11 methods.
3. Full adapter — implement Illuminate\Contracts\Container\Container over Aura. High cost (~30 methods, plus correct semantics for extend, contextual bindings, rebinding hooks, and scoped lifetimes). Only justified if a hard requirement mandates one container for the whole app.

Technical risk.

• Compile/scan path is the least mature surface. Thirteen 5.0.x patch releases, many of them classmap correctness fixes — missing root package, nonexistent attributes, classes extending nonexistent parents, incorrect classmap deletion on update. The runtime container is battle-tested; the bin/auradi scan + #[Blueprint] compilation toolchain is newer and still stabilising.
• Auto-locking. The container locks after the first get()/newInstance(). Developers trained on Laravel's mutable, always-available container will hit this. It is documented and correct, but it is a recurring onboarding injury.
• Serialization fragility. Closures in configuration break serialization. Build artifacts must be invalidated on deploy — stale compiled containers are a silent, hard-to-diagnose failure class.
• Attribute-driven configuration (#[Service], #[Instance], #[Value]) is elegant but invisible to IDE navigation and to Laravel-native debugging tooling (Telescope, artisan about, container dumps). Debuggability drops.
• Constraint alignment is good: PHP 8.0+, psr/container ^2.0 — satisfiable alongside Laravel 10/11/12.

Key questions.

• What is the actual driver — bootstrap latency, testability, or decoupling a package from Illuminate? Only the third is well served by this package.
• Does the target subsystem need the scanner/compiler at all, or would plain PHP config classes suffice (and eliminate most of the risk above)?
• Is composer/class-map-generator an install-time or build-only dependency? It determines whether it leaks into the app's production dependency tree.
• Does any consumer mutate the container after resolution? If yes, auto-locking is disqualifying.
• Who owns upgrade and fork risk if the Aura org goes quiet?

Integration Approach

Stack fit. Composer-installable, PSR-4, MIT, no external implementation dependencies — it will co-install cleanly with Laravel and Symfony packages. It does not fight the framework; it simply sits outside it. Treat that as the design constraint rather than a limitation to overcome.

Migration path (strangler fig, not cutover).

1. Spike (1–2 weeks). Stand up Aura.Di against one real, non-critical bounded context. Measure cold-boot time, config authoring effort, and compile-artifact behaviour in CI. Compare against the Illuminate container doing the same work. Most teams discover the bootstrap delta is small — Laravel boots once per worker under Octane and once per request under FPM, and the container is rarely the top cost.
2. Bridge. Add a Laravel service provider that pulls from the Aura container and registers into Illuminate\Container. Keep the boundary one-directional: Laravel may ask Aura for things; Aura must never ask Laravel.
3. Expand context by context. Move only new or self-contained modules (CLI tooling, queue workers, integration clients). Never migrate existing service providers in place.
4. Exit ramp. Because the boundary is PSR-11, swapping Aura for PHP-DI, Symfony's container, or a hand-rolled container is a config-file change, not a rewrite. Preserve that property deliberately.

Compatibility. Pin to ^5.0 with a committed lockfile; do not float across minors in production while the scan/compile path is still receiving correctness patches. Verify psr/container resolution against the app's Laravel minor before committing. Note the PHP 8.0 floor is below Laravel 11/12's 8.2 floor, so PHP version is a non-issue; the constraint that matters is psr/container major.

Sequencing recommendation. Do not proceed past the spike unless a measurable problem is being solved. The scoring signals here — 353 stars, 0 tracked dependents, opportunity score 21.5 — describe an adoption signal, not a quality signal. Code quality appears genuinely good (PSR-1/2/4/11 compliance stated, PHPStan, CI across PHP 8.4/8.5, maintained changelog). But with zero dependents you will find no prior art for Laravel integration and no community to lean on when the bridge misbehaves. Budget for owning that integration yourself.

Operational Impact

Maintenance. Small-vendor, low-bus-factor risk. The Aura organisation maintains a family of packages with a long release history and an active 5.0.x cadence, but the contributor base is thin. Practical mitigation: pin the version, keep the PSR-11 boundary so replacement is cheap, and pre-negotiate a fork-and-maintain contingency (a competent PHP engineer can own a container this size). Upgrades between majors have historically been breaking-and-documented (2→3→4→5 each carry migration guides), which is a positive signal for planning.

Support. Community support runs through a Google Group and GitHub issues — no Slack, no Discord, no commercial backing. There is no vendor SLA. If your organisation requires a named escalation path for production components, this package fails that gate for anything on the critical path. That is the single strongest argument for restricting it to non-critical, boundary-scoped subsystems.

Scaling. Container performance is almost never the throughput bottleneck; the compiled container primarily reduces bootstrap latency in cold-start scenarios (per-request FPM, CLI invocations, ephemeral job runners). Under Octane the app boots once per worker, so the benefit largely evaporates. Do not sell this adoption on performance without a benchmark from your own application — and expect that benchmark to be underwhelming.

Failure modes to instrument for.

• Stale compiled container after deploy — the highest-probability silent failure. Requires a build step in CI and a deployment gate that regenerates the artifact on any class-map-affecting change.
• Closure-containing config breaking serialization — surfaces late, at build time; enforce with a CI check.
• Auto-lock violations — container mutated after first resolution; surfaces as confusing runtime exceptions in code paths that worked under Laravel. Mitigate with a documented convention: use lazy*() variants.
• Classmap scan misses — attribute configuration silently not applied (the exact class of bug fixed repeatedly in 5.0.1–5.0.9). Requires an assertion in the test suite that expected services are wired, not merely that the app boots.
• Missing-attribute references from uninstalled libraries — fixed in 5.0.9, but indicative of fragility when scanning third-party code. Scope the scanner to first-party namespaces only.
• Lost observability — no Telescope or framework-native container introspection; plan for custom container-health assertions.

Ramp-up. A mid-level Laravel developer is productive in Laravel's container within days; Aura.Di's config-class model (params/setters/values arrays, ContainerBuilder, ContainerConfigInterface, configuration inheritance) is a genuinely different mental model. Estimate 1–2 sprints to fluency for the runtime container, and roughly double that for the attribute-scanning and blueprint-compilation path. Budget explicit onboarding documentation — none of it will be familiar, and the external docs, while complete, are oriented toward AuraPHP rather than Laravel.

Verdict. Adopt at the edge, not the core. Green-light a 1–2 week spike scoped to a framework-agnostic package; red-light any proposal to replace or wrap Illuminate\Container wholesale.