Di Laravel Package

Technical Evaluation

Architecture fit. hyperf/di is not a Laravel package — it is the standalone DI container extracted from the Hyperf framework, a coroutine-first, Swoole/Swow-based ecosystem. Its design center is fundamentally different from illuminate/container: it assumes a long-running worker process, resolves dependencies through PSR-11 plus annotation/attribute scanning, injects coroutine-local context via hyperf/context, and weaves AOP aspects through generated proxy classes. Laravel's container assumes per-request boot, deferred providers, facades, and contextual binding. There is no adapter, no service provider, and no facade bridge. Treating this as a "Laravel DI upgrade" is a category error; the realistic fit is either (a) an isolated, non-Laravel worker service inside our portfolio, or (b) a precursor to an actual framework migration. Score of 15.8 and 18 stars should be read carefully: hyperf/di is a read-only subtree split of the hyperf/hyperf monorepo, so stars and issue activity live upstream — the low count is a packaging artifact, not a health signal, but it does mean our normal OSS heuristics (issue velocity, contributor breadth) cannot be applied to this repo directly.

Integration feasibility. Standalone consumption is technically possible: the container is PSR-11 compliant and can be bootstrapped without the full framework, which makes it viable for a bounded CLI consumer, queue worker, or internal microservice. Inside an existing Laravel application it is close to infeasible without significant glue: two containers running side by side means two resolution graphs, two lifecycles, and ambiguous ownership of singletons. Annotation-driven autowiring also conflicts with Laravel's explicit binding conventions and with static analysis tooling. Effort to bridge is measured in weeks, not days, and the resulting hybrid is a long-term liability.

Technical risk. High. Key exposures: (1) hard runtime dependency on Swoole or Swow extensions, which constrains hosting (no standard php-fpm shared hosting, no vanilla PHP base images without custom builds); (2) coroutine-local state means container-resolved singletons behave differently than in Laravel — statics and request-scoped data bleed across coroutines if not handled correctly; (3) AOP requires proxy class generation and cache warm-up, which adds a build/deploy step and complicates debugging stack traces; (4) version cadence is pinned to Hyperf releases, so we inherit the framework's BC posture; (5) small split-repo surface means we consume a library whose governance, roadmap, and security response we do not have direct visibility into. MIT license is permissive and low-friction — that is the one clean signal here.

Key questions.

• Is there an actual, named workload that requires coroutine-scoped DI, or is this being evaluated because Laravel's container felt limiting?
• If the intent is Hyperf adoption, is the org prepared for a framework-level migration, or is this an attempt to import one component into a Laravel stack (an anti-pattern we should reject early)?
• Who owns the Swoole/Swow runtime in production — do we have platform support for it, or would this be the first service on that runtime?
• What is our exit cost if the container is abandoned upstream, given the 18-star split-repo optics?
• Does the AOP requirement justify the proxy-generation and debugging complexity, or is a Laravel middleware/decorator pattern sufficient?

Integration Approach

Stack fit. Poor fit as a Laravel dependency; reasonable fit as the container for a greenfield Hyperf-based service. Recommend scoping this evaluation explicitly to "new service on Hyperf" rather than "component added to an existing Laravel app." If the real requirement is better DI ergonomics inside Laravel, the correct answer is illuminate/container patterns (contextual binding, tagged services, #[Bind]-style attributes via community packages), not this package.

Migration path. If approved, do it as a standalone service, not as an injection into the monolith:

1. Stand up a single non-critical service (internal API or scheduled worker) on a Swoole/Swow base image with Hyperf's container only — not the full framework — to validate bootstrap, annotation scanning, and PSR-11 behavior.
2. Prove the boundary: that service must communicate with the Laravel estate over HTTP or a queue, never by sharing the container or autoloading Laravel service providers.
3. If that succeeds and there is appetite, expand to the full Hyperf framework for that service rather than growing a bespoke "Hyperf container inside Laravel" hybrid.
4. Only after two services are stable should framework migration of an existing Laravel app be on the table — and that is a separate, much larger decision.

Compatibility. Hard prerequisites: PHP 8.1+ (verify against our current floor), ext-swoole or ext-swow, and psr/container. Laravel-adjacent packages that assume illuminate/container or Illuminate\Contracts\Foundation\Application will not resolve. Composer conflicts are likely if any shared internal package type-hints against Laravel contracts. Audit shared libraries before committing.

Sequencing. (1) Confirm the business driver and the named workload. (2) Run a two-week spike validating runtime, deployment image, and observability on a throwaway service. (3) Security/license review and an upstream-health read against the hyperf/hyperf monorepo, not this split. (4) Decide go/no-go on the spike before any production commitment. (5) If go, gate on platform readiness for a long-running worker runtime.

Operational Impact

Maintenance. Moderate but non-trivial. The container itself is stable and mature upstream, but operational burden shifts to the runtime: Swoole/Swow extension upgrades, PHP version pinning, and a release cadence coupled to Hyperf. We would be adding a second PHP runtime profile to the platform — a permanent cost, not a one-time one.

Support. Internal expertise is the constraint. Our engineers are Laravel-shaped; coroutine semantics, AOP proxies, and annotation scanning are new mental models. External support is community-only via the Hyperf ecosystem; no commercial backing to lean on. Upstream responsiveness must be assessed on the monorepo, and we should record that the split repo's 18 stars is not the health indicator.

Scaling. Genuinely strong on the coroutine model — high concurrency per worker, low memory per connection, well suited to I/O-bound services. But scaling characteristics change shape: we size workers and coroutine pools rather than PHP-FPM processes, capacity planning models differ, and autoscaling signals are no longer "CPU per request." Existing runbooks and dashboards will not transfer.

Failure modes. Distinct from Laravel's: one coroutine's unhandled exception can affect shared worker state; static or container-singleton state leaks across requests in ways that are silent and intermittent; proxy class cache staleness after deploys causes resolution failures that only appear in production; memory growth in long-running workers requires restart policies and leak monitoring; and dual-container hybrids produce "service not found" errors whose origin is ambiguous. All of these are harder to reproduce locally than the equivalent Laravel failures.

Ramp-up. Estimate 4–6 weeks to productive for an experienced PHP engineer with no coroutine background, plus 2–3 weeks of platform work for the runtime image, health checks, graceful shutdown, and observability. If the decision is actually "adopt Hyperf," the real ramp is a framework migration measured in quarters, not weeks — and should be scoped and funded as such, not smuggled in as a container swap.

Recommendation. Do not integrate hyperf/di into the existing Laravel application. Approve at most a bounded spike inside a new standalone service if a coroutine-shaped workload is named and the platform can own a Swoole/Swow runtime. Otherwise, decline and address the underlying DI pain with illuminate/container patterns. Reassess upstream health against the hyperf/hyperf monorepo before any production commitment.