- Is hyperf/di compatible with Laravel?
- No. hyperf/di is the standalone PSR-11 container extracted from the Hyperf framework; it ships no Laravel service provider, facade, or adapter. Running it beside illuminate/container would create two resolution graphs and ambiguous singleton ownership. For Laravel applications, use illuminate/container features such as contextual binding and tagged services instead.
- How do I install hyperf/di via Composer?
- Install it with composer require hyperf/di. You then bootstrap the container yourself and register bindings through its PSR-11 API or Hyperf configuration. It is not auto-discovered by Laravel, so no package:discover step applies.
- What are the runtime requirements for hyperf/di, such as Swoole or Swow?
- Full Hyperf features assume a long-running Swoole or Swow worker process, not standard php-fpm. The container can run in plain PHP for basic PSR-11 use, but AOP, coroutine context, and lazy proxies depend on the Hyperf runtime. Check the composer constraints and confirm your platform supports the required extension.
- Does hyperf/di implement PSR-11?
- Yes. hyperf/di implements the PSR-11 ContainerInterface with get() and has(), so it can be consumed by any PSR-11-aware library. That interoperability does not make it a drop-in replacement for Laravel's container, which offers additional framework-specific behavior.
- How does annotation-based injection work in hyperf/di?
- hyperf/di scans classes for @Inject annotations or attributes and autowires constructor and method dependencies. This is annotation-driven autowiring rather than Laravel's explicit service-provider bindings. It requires class scanning and cache warm-up, and it can conflict with static analysis tools that expect explicit bindings.
- Can I use hyperf/di standalone without the full Hyperf framework?
- Technically yes: the container is PSR-11 compliant and can be bootstrapped without the full framework for a CLI tool, queue worker, or bounded microservice. In practice, features such as AOP proxies, coroutine-local context, and lazy loading pull in Hyperf components. Standalone use inside an existing Laravel app is not realistic without significant glue code.
- What does AOP support in hyperf/di require for deployment?
- AOP in hyperf/di works by generating proxy classes for intercepted methods, which adds a build or cache warm-up step to deployment. You must ensure proxy caches are generated and invalidated correctly. The proxies also make stack traces harder to read, so teams need debugging conventions.
- How do I test code that uses hyperf/di?
- Unit tests can instantiate classes directly or use a simple PSR-11 container with mocked bindings. Integration tests for AOP proxies and coroutine-scoped singletons need the Hyperf or Swoole runtime, which is heavier than Laravel's typical test setup. Avoid relying on container statics across coroutines in tests.
- Is hyperf/di actively maintained and production-ready?
- hyperf/di is a read-only subtree split of the hyperf/hyperf monorepo, so star counts and issue activity live on the upstream repository. The MIT license is permissive, but roadmap, security response, and BC cadence are governed by Hyperf releases. Treat the split repo's low star count as a packaging artifact, not a health signal, and assess upstream activity directly.
- What are the best alternatives to hyperf/di in a Laravel application?
- For Laravel, the natural alternative is illuminate/container with contextual binding, tagged services, and service providers. Community attribute-based binding packages can add #[Bind]-style ergonomics without a second container. Choose hyperf/di only if you are adopting Hyperf or building a service on the Swoole/Swow runtime.