- Can I use `sanmai/di-container` as a drop-in replacement for Laravel’s Service Container?
- No, this package is **not** designed for Laravel. Laravel’s container is hardcoded into the framework (e.g., `app()->bind()`) and integrates with service providers, facades, and middleware. This container lacks those features and would require manual reimplementation of Laravel’s DI patterns, which is unsupported and risky.
- How does autowiring work in this container? Does it support constructor injection?
- Autowiring is automatic via reflection—if a class’s constructor requires dependencies, the container resolves them without manual configuration. It supports constructor injection natively, but unlike Laravel, it doesn’t handle method injection or Laravel-specific features like `resolve()` or `when()` closures.
- Is this container compatible with Laravel’s service providers (register/boot methods)?
- No, this container has no integration with Laravel’s service providers. You’d need to manually rebind all dependencies, which defeats Laravel’s auto-registration system. For Laravel, stick to the built-in container or extract dependencies into a standalone library using this package.
- What’s the performance difference between this container and Laravel’s built-in one?
- This container is lightweight and optimized for simplicity, but Laravel’s container (PHP-DI based) is battle-tested for framework-specific use cases like route model binding, middleware, and queue workers. Benchmarking would be needed, but for Laravel apps, the built-in container is already optimized—this package offers no clear advantage.
- Does this support Laravel’s `app()->make()` or `resolve()` syntax?
- No, this container doesn’t integrate with Laravel’s `app()` facade or `resolve()` method. You’d need to create a custom wrapper to bridge it to Laravel’s container, which adds complexity and isn’t recommended. Use Laravel’s native container for framework-specific resolution.
- Can I use this container alongside Laravel’s container without conflicts?
- Technically possible but risky. If a dependency is registered in both containers, you’ll get duplicate instances or binding conflicts. Laravel’s container is the single source of truth for the framework—mixing containers requires manual synchronization, which is error-prone and unsupported.
- What PHP versions does this support, and will it work with Laravel’s legacy support?
- This package supports PHP 8.5+, but Laravel still supports PHP 7.4+. If you need to use this container in a Laravel project, you’d face version conflicts unless you isolate it to a non-Laravel component (e.g., a library). For Laravel apps, use the framework’s container for full compatibility.
- Are there any security risks or vulnerabilities I should know about?
- There’s no public evidence of security audits or dependency vulnerability scans for this package. Given its low adoption (7 stars, 0 dependents), it’s untested in production environments. For Laravel, always prioritize the framework’s container, which undergoes regular security reviews.
- How do I configure shared vs. non-shared services in this container?
- By default, this container reuses instances (shared). To create a non-shared instance, use the `get()` method directly without binding it. For shared services, bind them with `set()` or `bind()`, e.g., `$container->set(Logger::class, fn() => new Logger())`. Unlike Laravel, there’s no `singleton()` method—use `set()` for shared bindings.
- What are the alternatives to this container for Laravel projects?
- For Laravel, **never replace the built-in container**. Instead, use Laravel’s native DI for full framework integration. If you need a lightweight container for a **non-Laravel** component (e.g., a library), consider PHP-DI, Symfony’s DI, or Laravel’s container in isolation. This package is only suitable for standalone PHP apps, not Laravel.