Di Laravel Package

Product Decisions This Supports

• Framework/runtime selection: Informs whether to standardize on Hyperf (Swoole/Swow coroutine runtime) versus Laravel/Symfony for a PHP service. This package is the DI layer of Hyperf, not a Laravel component, so the real decision is framework-level, not library-level.
• Build vs. buy: Supports “buy/consume” for dependency injection, annotation scanning, AOP proxying, and coroutine-context-aware object lifecycle instead of building an in-house container. DI is commodity infrastructure; custom builds rarely differentiate the product.
• Architecture roadmap: Enables annotation-driven service wiring and aspect-oriented concerns (logging, transactions, rate limiting, auth) as cross-cutting modules. Useful when planning a service platform with many small coroutine-safe components.
• Feature delivery: Reduces boilerplate for controllers, services, repositories, and event listeners; supports faster iteration on backend features once the Hyperf runtime is already in place.
• Ecosystem and lock-in review: A dependency on hyperf/di is effectively a dependency on the Hyperf component model. This should trigger a deliberate vendor/runtime risk decision, especially for teams with Laravel or Symfony experience.
• Use cases: High-concurrency PHP APIs, microservices, WebSocket/TCP services, and teams already using Hyperf. Poor fit for conventional Laravel CRUD apps, WordPress, or teams unwilling to operate Swoole/Swow.

When to Consider This Package

• Adopt when the product is already committed to Hyperf or evaluating it, and the team needs the framework’s native container, annotation injection, AOP, and coroutine-safe singleton handling.
• Adopt when you want PSR-11-compatible DI behavior inside the Hyperf ecosystem without assembling a custom container.
• Consider when you need aspect-oriented programming at the framework layer — e.g., declarative transactions, caching, or authorization — and prefer configuration/annotations over manual decorators.
• Consider with caution when the team is Laravel-first. Laravel’s Illuminate\Container already provides auto-resolution, contextual binding, and tagging; replacing it with Hyperf DI means changing frameworks, not swapping a package.
• Look elsewhere when you need a framework-agnostic container: PHP-DI, Symfony DependencyInjection, or Laravel’s container are better-supported standalone choices.
• Look elsewhere when the operational model cannot tolerate coroutine runtimes, long-running workers, or the Swoole/Swow extension requirements.
• Look elsewhere when community size, hiring pool, and third-party package breadth are primary concerns. The 18 GitHub stars reflect this being a low-level split package, but the surrounding Hyperf ecosystem is materially smaller than Laravel or Symfony.
• Diligence item: confirm the release cadence and version alignment with hyperf/framework; this package should be consumed as part of a pinned Hyperf stack, not adopted independently.

How to Pitch It (Stakeholders)

• For executives: This is not a product differentiator; it is infrastructure plumbing. It can reduce backend glue code and accelerate delivery only if we are already standardizing on Hyperf. It does not create customer-facing value by itself.
• For engineering leadership: hyperf/di provides a mature-pattern DI container with annotations, AOP, and coroutine-aware lifecycle management. MIT license and active releases lower licensing risk. The real risk is runtime and ecosystem lock-in to Hyperf, plus a smaller hiring and support pool than Laravel/Symfony.
• For engineering teams: It removes manual wiring and supports clean cross-cutting concerns, but it is not a drop-in Laravel package. Adopting it implies adopting Hyperf’s conventions, annotation scanning, and coroutine execution model.
• Recommendation: Treat this as a framework-level evaluation, not a standalone package purchase. Run a time-boxed spike only if Hyperf is already on the roadmap. If the product is Laravel-based, do not adopt; use Laravel’s native container. If Hyperf is strategic, consume hyperf/di via the pinned framework distribution, document the lock-in, and validate operational readiness for Swoole/Swow before committing.