Di Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use-the-framework for DI wiring. This package forces the question "do we need a third-party container at all?" In a Laravel codebase, the answer is almost always no — Illuminate\Container already provides autowiring, contextual binding, tagging, aliases, and extend-based decoration. Evaluating Orno is really a decision to reject a build/buy evaluation and standardize on the framework primitive.
• Legacy modernization roadmaps. If an inherited service, CLI tool, or pre-Laravel module ships with Orno, the PM decision is a migration ticket: map constructor dependencies, port bindings to service providers, delete the vendor dependency. This is a "reduce surface area / reduce supply-chain risk" line item, not a feature line item.
• Third-party integration risk review. Any library that drags its own container into your dependency graph is a compatibility and security-review item. Orno's zero stars / zero dependents / no release cadence is a red flag that belongs in procurement and vendor-risk discussions.
• SDK and extension-point design. If your product exposes plugin hooks, a container is a plausible internal mechanism — but choosing an unmaintained one to avoid a framework coupling is a false economy. Decision: use the host framework's container or a maintained PSR-11 implementation.
• Interviewing and platform standards. Codifying "we use the framework container" as an engineering standard removes a recurring, low-value architecture debate and shortens onboarding.

When to Consider This Package

Consider only if all of the following are true:

• You are maintaining a legacy, non-Laravel PHP codebase (circa PHP 5.x) where Orno is already in the lockfile and removing it is not currently funded.
• You need lightweight automatic constructor resolution in a small CLI tool or microservice with no framework present.
• You have verified it satisfies your PSR-11 (Psr\Container\ContainerInterface) requirements — Orno predates PSR-11's finalization, so confirm interoperability before assuming compliance.
• You have accepted vendor fork/patch ownership, since upstream maintenance is effectively absent.

Look elsewhere in every other case:

• Any greenfield Laravel work — use Illuminate\Container, app(), service providers, and contextual binding. Zero new dependency, better docs, active security process.
• PSR-11 compliance is a hard requirement — use php-di/php-di or league/container; both are maintained and widely adopted.
• You need compile-time/optimized containers, tags, lazy proxies, or AOP — Symfony DI or PHP-DI cover this with real ecosystems.
• You care about supply-chain hygiene — zero stars and zero dependents means no community triage of bugs or CVEs, and no realistic chance of upstream fixes.
• You need PHP 8.x compatibility guarantees — verify composer.json constraints and run your own test matrix before betting a roadmap on it.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated orno/di, a small PHP dependency-injection container, and recommend not adopting it. The package has no community traction (zero stars, zero dependents) and no visible maintenance signal, which means every bug or security issue becomes our problem to fix and every new hire has to learn a bespoke tool. Laravel already ships a more capable container at no additional cost, so adoption would add risk and total cost of ownership while delivering no incremental capability. The only commercial justification for touching this package is a funded cleanup of legacy code that already depends on it — treat that as technical debt retirement, not a platform choice.

To engineering (summary): Orno's value proposition — automatic constructor resolution and a compact API — is already fully covered by Illuminate\Container in our stack, with strictly better ergonomics: contextual binding, interfaces to implementations, tagging, aliasing, deferred providers, and extend for decoration. Adopting Orno would mean maintaining a second container, fighting two resolution strategies, and hand-rolling PSR-11 interop that the framework provides for free. Where we operate outside Laravel, standardize on a maintained PSR-11 implementation (php-di/php-di or league/container) rather than an unmaintained one. If Orno appears in a legacy service, scope a migration spike: inventory bindings, port them into service providers or a maintained container, and remove the dependency. No new code should introduce orno/di.