- Is orno/di compatible with Laravel?
- Not in any practical sense. Laravel's service container, Illuminate\Container, is load-bearing for service providers, facades, controller method injection, and package discovery, so there is no seam where orno/di can be substituted without rewriting bootstrapping. Running it alongside Laravel creates two singleton registries and ambiguous resolution, so it is not recommended for Laravel applications.
- How do I install orno/di with Composer?
- Install it with composer require orno/di, but first confirm the repository has a valid composer.json, autoload map, and PHP version constraints for your runtime. Because the package is unmaintained and may predate modern PHP, treat installation as a spike rather than a production commitment. If you need a maintained PSR-11 container, evaluate PHP-DI or league/container instead.
- Does orno/di support autowiring and constructor injection?
- Yes. The package description and blurb state that it provides automatic resolution of dependencies, constructor and setter injection, aliases, lazy resolution, and shared instances. In a standalone PHP service this can reduce manual wiring. In Laravel, however, autowiring is already provided by Illuminate\Container, so the feature does not justify adding a second container.
- Is orno/di PSR-11 compliant?
- The blurb describes it as PSR-11 compatible, but the technical assessment notes that the package predates PSR-11 and may require an adapter before it can satisfy a standard ContainerInterface consumer. Verify the actual interface implementation in the repository before depending on it. If downstream code requires PSR-11, an adapter is mandatory scope unless the package proves otherwise.
- Which PHP versions does orno/di support?
- That is uncertain from the available context. The package appears to be authored in PHP 5.3/5.4 style and predates modern Composer and scalar type hint conventions, so compatibility with PHP 8.x must be verified with a spike. Check composer.json constraints and run the test suite under your target PHP version before adopting it.
- Can I use orno/di alongside Laravel's container?
- You can technically register a second container inside a Laravel app, but it is a bad idea. You would end up with two competing singleton registries, ambiguous resolution order, and confusing failures when a class resolves differently depending on which container is asked. If you have a bounded standalone use case, isolate it in its own composer.json and service rather than wiring it into the Laravel application.
- Is orno/di maintained and safe for production?
- The assessment flags it as unmaintained, with a 0-star and 0-dependent profile and no observable consumer base. That means no upstream security response, no PHP version guarantees, and no clear path to a CVE fix. Supply-chain risk is modest because the package is small, but the real risk is silent behavioral divergence and the bus factor of one unknown maintainer.
- What are better alternatives to orno/di for a standalone PHP service?
- For a non-Laravel service, PHP-DI and league/container are stronger choices because both are maintained and PSR-11 compliant. If the service may later merge back into Laravel, those libraries also have bridges or clearer migration paths. Treat orno/di as a reference implementation to read rather than a runtime dependency to adopt.
- How do I test a Laravel application that uses orno/di?
- Testing a Laravel app with a second container is awkward because the framework's test helpers, facades, and container-bound mocks assume Illuminate\Container is authoritative. You would need to explicitly test both resolution paths and assert that no class resolves differently depending on which container is asked. A cleaner approach is to avoid the second container and test against Laravel's native container instead.
- Should I adopt orno/di in a new project?
- Usually no. The value proposition, reflection-based autowiring, is now commodity functionality available from maintained libraries, and the package has no observable consumer base. Adopt it only if you are deliberately studying its implementation or have a legacy constraint you cannot escape. For new code, choose a maintained PSR-11 container or use Laravel's built-in container when you are in Laravel.