Di Laravel Package

Product Decisions This Supports

• Build vs. buy for dependency injection: Aura.Di is an MIT-licensed, PSR-11-compliant container with constructor and setter injection, interface and trait awareness, configuration inheritance, lazy values, and optional container compilation. That is a meaningful amount of undifferentiated plumbing you do not have to design, build, document, or maintain yourself — if you actually need a container outside of Laravel.
• Framework-decoupling strategy for shared packages: The strongest PM-relevant use case is a library or internal package that must run under Laravel and another runtime (CLI worker, queue consumer, standalone microservice, another framework). Because Aura.Di is framework-agnostic and only depends on interfaces, it lets you publish a package with a real DI story that does not drag illuminate/container into non-Laravel consumers.
• Architecture investment in a framework-independent domain layer: If your roadmap includes extracting domain/service code out of Laravel service providers — for testability, for reuse in a second product, or as an escape hatch from framework upgrades — Aura.Di is a credible reference implementation and a workable runtime container for that layer.
• Performance-sensitive boot paths: The 5.x line adds a compile step (bin/auradi, blueprint generation, class-map scanning) and the container has historically been serializable (excluding closures). That is directly relevant to cold-start-sensitive workloads: serverless handlers, per-request CLI invocations, and batch jobs where container reflection cost is paid repeatedly.
• Configuration ergonomics as a differentiator: PHP 8 attributes (#[Service], #[Instance], #[Value], #[Blueprint]) plus AttributeConfigInterface let a team express wiring next to the code instead of in sprawling provider classes. This is a legitimate design-position question for internal platform teams: "explicit declarative config" vs. Laravel's auto-resolution-plus-providers model.
• Roadmap signal — not a Laravel container replacement: This should not be framed as an alternative to Illuminate\Container. Laravel's container is load-bearing across the framework (facades, gates, queue, events, HTTP kernel), and swapping it is not a product decision, it is a fork. Any proposal that implies "replace Laravel's container" should be rejected at the roadmap level.
• Vendor/risk diligence input: 353 stars, effectively zero recorded dependents, community support via a Google Group, and releases driven by a small maintainer group. That is a concrete input to a build-vs-buy or dependency-approval decision, and it should be recorded as such rather than discovered later.

When to Consider This Package

Consider it when:

• You are building a standalone PHP 8.0+ application or library outside Laravel and want a small, PSR-11-compliant container with good documentation and no framework coupling.
• You are shipping a Composer package that must remain framework-agnostic, and you need a container you can depend on without pulling in Illuminate or Symfony components.
• You need explicit, testable wiring — constructor/setter injection, interface-to-implementation mapping, configuration inheritance, contextual parameters — and prefer declarative config over runtime auto-wiring magic.
• Your boot path is repeated or latency-sensitive and you can benefit from container compilation and/or serialization.
• You want a teaching/reference implementation of DI concepts for an internal architecture spike or a "should we extract this from Laravel?" evaluation. The docs and changelog are mature enough for that.

Look elsewhere when:

• The product is a Laravel application. Use Illuminate\Container. There is no service provider, no facade bridge, no Eloquent/queue/event integration here, and the integration work would be yours to own permanently.
• You need autowiring with broad ecosystem tooling — compiler passes, tags, decoration, config caching, and battle-tested framework integrations. Symfony DI or PHP-DI are the lower-risk choices on adoption and hiring grounds.
• You need commercial support, a large hiring pool, or a broad community answer base. Aura's support channel is a Google Group; Slack/Discord/StackOverflow depth is thin.
• Your dependency policy requires demonstrable downstream adoption. With effectively no recorded dependents, this will fail most enterprise third-party risk reviews without an internal champion and an exit plan.
• You need PHP < 8.0 for legacy services. The 5.x line requires PHP 8.0+; older majors exist but are on a maintenance-only trajectory.
• You are not prepared to own an abstraction boundary. If nobody on the team will maintain the container config, the compile step, and the framework bridges, the "buy" turns into a hidden "build."

Adoption criteria (checklist): PHP 8.0+ runtime confirmed · use case is outside or orthogonal to Laravel's container · team accepts PSR-11 as the contract · an owner is named for container config and upgrades · a documented fallback exists if the package stops receiving releases · a spike proves the compile/serialize path works under your deployment model.

How to Pitch It (Stakeholders)

For executives (one paragraph): Aura.Di is a small, MIT-licensed dependency injection library for PHP. It is not a replacement for Laravel's built-in container and would not change how our Laravel product runs today. Its value is narrow but real: it lets us write shared PHP code and internal packages that are not welded to Laravel, and it offers a compiled/serializable container for latency-sensitive workloads. The trade-off is ecosystem risk — it has a few hundred stars, no meaningful downstream adoption, and community support through a Google Group. Recommendation: approve it for a bounded, time-boxed evaluation inside one decoupled package or service, not as a platform standard. Cost is effectively zero in licensing; the real cost is the engineering owner we assign to it.

For engineering (the practical summary): PSR-11 container, PHP 8.0+, constructor and setter injection, interface and trait awareness, config inheritance, contextual parameters, lazy values, and — in 5.x — attribute-driven configuration (#[Service], #[Instance], #[Value], #[Blueprint]) with a compile step and a bin/auradi scan command. Docs, changelog, and releases are well maintained; CI covers current PHP versions; PHPStan is in play. What it does not give you: any Laravel integration, autowiring ecosystem tooling in the Symfony/PHP-DI sense, or a large community. Treat it as a library you own: pin the version, isolate it behind your own container interface, and keep the surface area small. If the goal is "make our Laravel app's DI nicer," this is the wrong tool and the answer is no. If the goal is "ship a package or service that must run outside Laravel," this is a reasonable, low-cost candidate worth a spike.