Php Di Laravel Package

Technical Evaluation

Architecture fit

• PHP-DI is a standalone PSR-11 container with autowiring, attribute/PHP-config definitions, decorators, and an optional compiled container. It competes directly with Illuminate\Container, which Laravel already ships and which is itself PSR-11 compliant.
• Inside a Laravel application the fit is poor: adopting PHP-DI creates two containers, two lifecycle owners, and an ambiguous answer to "who resolves this class?" That ambiguity is a recurring source of production incidents and onboarding friction, and it buys almost nothing — Laravel's container already does autowiring, singletons, contextual binding, and interface binding.
• The genuine fit is at the boundary: framework-agnostic packages, standalone services (Slim + PHP-DI is the canonical pairing), CLI tooling, queue workers and serverless handlers that must not carry Illuminate/*, and test harnesses that need to boot a class graph without a full framework.
• Its strongest strategic property is that PSR-11 is the contract. A package typed against Psr\Container\ContainerInterface runs under Laravel, Symfony, and PHP-DI unchanged. PHP-DI is useful to us less as a runtime and more as the reference implementation that proves our shared libraries are container-agnostic.

Integration feasibility

• Mechanically easy. Interop is a two-line adapter: hand PHP-DI's container to Laravel as Psr\Container\ContainerInterface, and register PHP-DI as a Laravel binding for consumers that type-hint PSR-11. No fork, no patching.
• The API surface is small (get, has, set, factory, autowire, DI\create/DI\get/DI\env), and PHP 8 attributes cover most definition needs. A Laravel developer is productive in a day.
• MIT license, no commercial entanglement, no runtime services, no vendor lock-in. Integration cost is dominated by architecture decisions, not by code.

Technical risk

• Redundant container ownership is the primary risk — not a library defect but a governance failure mode. Without an explicit rule ("PHP-DI governs namespace X; Laravel governs everything else"), definitions will drift across both.
• Compiled-container cache is a deployment artifact. It requires a writable, per-release directory; stale caches after config changes produce silently wrong wiring; multi-node deploys must invalidate consistently. Opcache preloading and read-only container filesystems need explicit validation.
• Lazy injection depends on a proxy-generation library whose upstream maintenance has historically been fragile. Any use of lazy services should be treated as a supply-chain question, not a feature toggle.
• Autowiring resolves by reflection at runtime. Union types, untyped scalars, variadics, and constructor params without defaults fail at resolution time, in production, not at build time. Nothing in a standard Laravel CI pipeline catches this; we would need a dedicated container-warm/validate step.
• Attribute-based definitions place container metadata inside domain classes, which conflicts with a clean-architecture posture and makes those classes non-portable.
• Bus factor: small maintainer base and low release cadence. The code is stable and the surface is narrow, so fork risk is low, but "no one is home" risk is real and should be priced in.

Key questions

• Is the actual target a Laravel app (low value, high confusion) or a framework-agnostic library/service we ship (clear value)?
• Will we permit container attributes in domain code, or restrict definitions to config files?
• Do we need lazy/proxy services at all? If yes, who owns that dependency's lifecycle?
• What is our deployment topology — writable per-release cache directory, opcache preload, read-only root filesystem?
• Which CI gate proves the container graph is constructible before deploy?
• What is the exit cost if maintenance stops — is the container isolated behind our own PSR-11 boundary?

Integration Approach

Stack fit

• Best fit: standalone PHP services and packages where Illuminate/* is unwanted — Slim, PSR-15 middleware stacks, Lambda/Bref handlers, long-lived queue workers, internal CLI tools, and shared libraries consumed by multiple frameworks.
• Poor fit: the Laravel HTTP kernel. Do not attempt to replace Illuminate\Container in a running Laravel app; the framework's facades, service providers, queue, and testing helpers all assume it.
• Acceptable fit: a Laravel monolith that also publishes composer packages. Here PHP-DI lives in the package's own test suite and reference bootstrap, never in the host app.

Migration path

• Do not migrate. There is no defensible case for moving a Laravel application onto PHP-DI — the effort is large, the benefit is negative, and the rollback is messy.
• Instead, adopt in three concentric rings: (1) package test harnesses, where PHP-DI boots the graph without Laravel; (2) greenfield standalone services, where PHP-DI is the container from day one; (3) optional PSR-11 adapters in the Laravel app so framework code can consume those packages without special-casing.
• For any existing service already using a hand-rolled container or service locator, PHP-DI is a reasonable consolidation target because autowiring removes boilerplate and the compiled container removes the performance objection.

Compatibility

• Requires PHP 8.x on the current line; attribute-based configuration assumes PHP 8. Laravel 10/11 satisfy this. Anything pinned to PHP 7.4 must stay on the older major and should be treated as legacy.
• PSR-11 is the compatibility seam in both directions. Verify the exact psr/container major against Laravel's constraint before adding the adapter — a version skew here surfaces as an interface-mismatch fatal at boot.
• Compiled container output is PHP-version- and opcache-sensitive; cache directories must be namespaced by release.

Sequencing

1. Spike: stand up PHP-DI in a non-production path (a CLI command or a package's test bootstrap) and measure cold-start with and without compilation.
2. Publish the container-ownership policy before any production adoption — which namespaces, which container, which direction adapters flow.
3. Add CI validation that the container graph resolves for every registered service.
4. Roll out to one bounded standalone service, with compiled-cache invalidation wired into the deploy pipeline.
5. Only then expose PSR-11 adapters into the Laravel monolith, and only for package consumption.

Operational Impact

Maintenance

• Low ongoing effort: narrow API, stable behavior, infrequent releases, MIT. Upgrades between majors are small and mostly PHP-version-driven.
• The hidden cost is owning a second container's upgrade path alongside Laravel's. Every PHP or psr/container bump now has two upgrade surfaces, and the one with fewer maintainers will lag.
• Compiled-container artifacts add a build step to CI/CD that must be owned by someone. It is small but it is permanent.

Support

• Documentation is genuinely good and standalone; the "for humans" positioning is accurate. There is no Laravel-specific guidance, so internal documentation is on us.
• Support channel is GitHub issues plus community chat. No vendor SLA. For an internal platform dependency this is acceptable; for anything customer-facing and latency-critical, it argues for keeping PHP-DI behind our own interface.

Scaling

• Compilation helps cold-start-bound workloads: serverless invocations, per-request PHP-FPM with large graphs, and CLI tools. This is the one place PHP-DI outperforms a naive reflection container.
• Under Laravel Octane or any long-lived worker, autowiring cost is amortized after the first resolution, so the compiled-container advantage largely evaporates. Do not justify adoption on performance grounds in an Octane deployment.
• No shared state, no external services, no cluster concerns. Scaling risk is effectively zero.

Failure modes

• Unwritable or missing compiled-cache directory at boot → hard fatal, typically first request after deploy.
• Stale compiled container after a definition change → wrong object graph in production, no error surfaced; hardest failure to diagnose.
• Unresolvable constructor parameter (scalar without default, union/intersection type, interface without binding) → runtime exception on the code path that first requests it, not at deploy.
• Proxy/lazy-service generation failures under restricted filesystems or opcache preload.
• Definition drift between two containers → a class resolved from the wrong scope, producing duplicate singletons or lost state. This is the signature failure of dual-container setups.
• Maintainer abandonment → no security patches; mitigated by MIT and a narrow surface, but requires an internal fork contingency.

Ramp-up

• Individual learning curve is shallow — a day for a competent Laravel developer to be productive, a week to be fluent in compilation and attributes.
• Organizational ramp-up is the real cost: the team must internalize the ownership policy, the CI validation gate, and the deploy-time cache invalidation. That is a half-day of documentation and one pipeline change, but it must exist before the first production service.
• Recommend naming a single owner for the container boundary (definitions, adapters, cache strategy) rather than distributing that responsibility across teams — dual-container architectures fail by diffusion of ownership, not by technical defect.