orno/di
Orno\Di is a lightweight, PSR-11 compatible dependency injection container for PHP. It supports constructor and setter injection, autowiring, lazy service resolution, aliases, and shared instances, making it easy to wire dependencies cleanly in small applications and custom frameworks.
Architecture fit. Orno\Di is a standalone dependency injection container with auto-wiring (reflection-based constructor resolution). Architecturally it competes with, rather than complements, Illuminate\Container, which is the backbone of Laravel: the service container is what powers service providers, facade resolution, contextual binding, method injection into controllers and jobs, and the entire package auto-discovery lifecycle. There is no seam in a Laravel application where a second container can be substituted without rewriting the framework's bootstrapping. The realistic fit is therefore not Laravel at all — it is a small standalone PHP service, a CLI tool, or a legacy codebase predating Composer-era DI. Even there, the package's value proposition (auto-resolution) is now commodity functionality available from maintained libraries.
Integration feasibility. Low. The package predates PSR-11 (the container interoperability standard), so it cannot be dropped in behind a standard ContainerInterface expectation without an adapter you would have to write and own. Its era of authorship (PHP 5.3/5.4 style, pre-Composer-2, likely pre-scalar-type-hints) makes compatibility with PHP 8.x uncertain at best and requires a spike to confirm. There is also a concrete collision risk: registering a second container inside a Laravel app means two competing singleton registries, ambiguous resolution order, and confusing failure modes when a class resolves differently depending on which container is asked.
Technical risk. High and asymmetric. The 0-star, 0-dependent profile is the dominant signal — this is an unmaintained package with no observable consumer base, which means no upstream security response, no PHP version compatibility guarantees, and no path to a CVE fix. Supply-chain risk is modest only because the package is small and dependency-light; the real risk is silent behavioral divergence between two containers and the bus-factor of one unknown maintainer. Downside is unbounded (framework-level breakage); upside is marginal (you could write the same auto-wiring in ~150 lines).
Key questions.
Illuminate\Container or to run alongside it in a bounded context? The former is not viable; the latter needs a hard justification.Illuminate\Container or PHP-DI is being solved that this package addresses better?Stack fit. Poor for Laravel, neutral-to-poor for generic PHP. Assume Laravel means Illuminate\Container is non-negotiable: it is load-bearing for the framework, not a swappable component. Do not attempt container substitution. If a genuine standalone use case exists (a queue worker, a CLI, a legacy module being carved out), scope it as an isolated service with its own composer.json, not as a dependency of the Laravel application.
Migration path. There is no migration path to this package that a TPM should sponsor, because it is a net-new dependency rather than a step in an existing trajectory. If a team is currently hand-rolling new Foo(new Bar()) wiring in a non-Laravel service, the correct migration target is PHP-DI or league/container — both maintained, both PSR-11 compliant, both with Laravel bridges if the service ever merges back. Treat orno/di as a reference implementation to read, not a runtime dependency to adopt.
Compatibility. Verify before anything else: PHP version support, presence of composer.json with a valid autoload map, and whether it declares a PSR-11 or container-interop dependency. Absent these, assume it will need a fork to run under modern PHP, which converts a "cheap small package" into an owned-and-operated internal library — a materially different cost.
Sequencing. If leadership insists on evaluation: (1) timebox a one-day spike confirming PHP 8 compatibility and basic auto-wiring behavior; (2) prototype the PSR-11 adapter; (3) benchmark against PHP-DI on the same fixture; (4) present the fork-vs-adopt tradeoff with the maintenance cost of the fork made explicit. Expect the spike to terminate the evaluation. Do not sequence this ahead of any framework-version upgrade work; it is strictly optional-scope.
Maintenance. Effectively zero upstream. With 0 stars and 0 dependents there is no contributor pipeline, no issue triage, and no release cadence — any bug becomes your bug on day one. Budget the fork explicitly if adopted: ownership of the composer.json, PHP version matrix, CI, and security response rests entirely with your team, for a component that provides commodity functionality.
Support. No vendor, no community, no Stack Overflow corpus. Onboarding answers come from reading the source. For a container — the component every other component resolves through — that is the wrong place to accept a knowledge gap.
Scaling. Runtime scaling is a non-issue; DI containers are not hot paths in any meaningful sense (reflection-based auto-wiring costs microseconds and is cacheable, though this package predates compiled-container optimizations, so expect slightly higher per-request reflection cost than Symfony's dumped container). The real scaling constraint is organizational: the container's API surface becomes a defacto internal standard, and standardizing on an unmaintained library does not scale past the team that adopted it.
Failure modes. (a) Silent divergence — a class resolves via Illuminate\Container in an HTTP request but via Orno\Di in a queued job, producing two singleton instances and duplicated side effects. (b) PHP upgrade breakage with no upstream fix, forcing an emergency fork mid-upgrade. (c) Reflection failures on classes with union types, promoted constructor properties, or intersection types — all post-2015 PHP features the package cannot know about. (d) Circular dependency detection gaps producing stack-depth fatals rather than clear errors.
Ramp-up. Low to learn the API (a container is a container), high to learn the failure modes, because there is no documentation ecosystem to consult. The realistic ramp-up cost is "one engineer reads the entire source," which for a 150-line package is cheap — and is precisely why forking it, or better, using a maintained alternative, dominates adoption.
Recommendation. Do not adopt. The package is a reasonable teaching artifact and a poor production dependency. Where auto-wiring is genuinely needed outside Laravel, standardize on PHP-DI or league/container; inside Laravel, use Illuminate\Container and its contextual-binding features. Revisit only if a concrete, documented gap in maintained alternatives emerges — no such gap is evident at 0 stars and 0 dependents.
How can I help you explore Laravel packages today?