Container Laravel Package

Product Decisions This Supports

• Build vs. buy for internal CLI tooling. This package lets you avoid hand-rolling service wiring in scripts and cron jobs, and avoids pulling a full framework (Laravel/Symfony) into a command-line tool just to get dependency injection. The decision it supports: standardize small internal tools on a PSR-11 container rather than ad-hoc new chains or framework lock-in.
• Framework decoupling roadmap. Because it implements PSR-11, you can commit to a container-agnostic contract for internal tools and defer the "which framework?" decision. This is a cheap option to keep open, especially for teams with Laravel-shaped skills building non-Laravel utilities.
• Long-running process architecture. Scopes and explicit destruction are the differentiators worth a product decision: for daemons, queue consumers, and batch jobs, they give deterministic resource release (DB connections, file handles) without a framework's lifecycle. This influences whether you build state-reset logic yourself or adopt it.
• Convention-over-configuration investment. Autowiring plus inflectors means fewer per-command registration files; the PM decision is whether to codify team conventions (e.g., auto-decorating loggers or repositories) as inflectors shared across tools, versus documenting manual wiring. As of 1.1.0, scope-sharing can also be declared declaratively via the #[ScopeShared] attribute (PHP 8.1+), which shifts the decision from "how much bootstrap config do we tolerate?" to "do we standardize on attribute-driven scope declaration as a team convention?" — a lower-ceremony pitch to engineers, but one that requires a PHP 8.1 floor and a documented convention to avoid mixing attribute and code-based registration styles in the same codebase.
• Use-case fit: internal Artisan-like command suites, data migration/backfill scripts, scheduled jobs, developer tooling, and microservice bootstrapping where you want DI hygiene but not an application framework.
• Risk posture decision. With 0 stars, 0 dependents, and a low composite score (17.96), the real decision is not "is this good?" but "do we adopt, fork, or vendor-pin?" The BSD-3-Clause license makes forking viable; treat it as source you own rather than a dependency you rely on. The 1.1.0 release is additive and non-breaking, which is mildly reassuring on maintenance direction but does not change the external-validation picture.
• Not a Laravel feature decision. This does not extend or replace Laravel's container in Laravel apps. If the roadmap item is "improve DI in our Laravel product," this package is out of scope; if it's "reduce framework footprint in our internal CLI estate," it is in scope.

When to Consider This Package

Consider it when:

• You are building small, internal, non-Laravel CLI tools and want autowiring without Symfony DI's configuration surface.
• You specifically need scoped bindings (per-job or per-command state) and explicit destruction semantics in a long-running process, and would otherwise write that lifecycle code yourself. As of 1.1.0 these can be declared with the #[ScopeShared] attribute, which is a meaningful ergonomics win if your team already leans on attributes.
• Your team already accepts PSR-11 as an internal standard and wants container portability.
• You are on PHP 8.1+ and want attribute-based scope declaration; teams pinned below 8.1 should stay on the 1.0.x line or plan the upgrade as part of adoption.
• You are comfortable vendoring or forking a small, permissively licensed codebase and pinning a version.
• You can validate it with a time-boxed spike against your PHP version and autoloading setup before committing. The 1.1.0 change is a good spike target: confirm the attribute is discovered correctly under your autoloader/composer setup and behaves identically to the existing code-based scope registration.

Look elsewhere when:

• You are already on Laravel or Symfony. Use the framework's container; adding a second container is duplicate wiring, confused resolution order, and onboarding cost for no product benefit.
• You need config loading, events, HTTP, queues, or DB abstractions — that is a framework decision, not a container decision.
• You need compiler passes, tagged services, YAML/PHP config, AOP, or lazy proxies — Symfony DI is the mature answer.
• You need proven ecosystem signal, security policy, or support guarantees. 0 stars and 0 dependents is not proof of poor quality, but it is an absence of external validation; the new README badges are cosmetic and do not substitute for it. For anything on a critical path, prefer PHP-DI, League\Container, or Symfony.
• The internal/ namespace and zero dependents suggest this may be an internal-only package not intended for external adoption. Confirm intent and maintenance ownership before betting roadmap on it.
• Provenance checks fail: verify commit history, test coverage, CI status, supported PHP versions, and the release record (the 1.1.0 and prior 2026-09-08 dates should be confirmed as accurate rather than a metadata artifact). The 1.1.0 entry references a single feature commit plus a docs commit — a thin but coherent release; check that CI actually exercises PHP 8.1 now that it's the announced target.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost enabler for our internal tooling, not a customer-facing bet. It reduces boilerplate in CLI scripts and lets us keep tooling independent of any one framework, which lowers future migration cost. Version 1.1.0 added PHP 8.1 attribute support — a developer-ergonomics improvement, not a change in the risk profile. The package is still immature by external measures (no stars, no known dependents), so the recommendation stands: a contained pilot with the code vendored under its BSD-3 license — capped effort, no critical-path exposure, and an easy exit.

To engineering: PSR-11 container with autowiring, scopes, inflectors, and explicit destruction — the last two are the reason to look. Scopes and deterministic teardown solve real problems in long-running CLI workers that we currently hand-roll, and 1.1.0 lets you declare shared scopes with #[ScopeShared] instead of registration code. The release is additive and non-breaking; the only real gate is the PHP 8.1 floor, so confirm our tooling fleet is there before adopting. The API surface is small and the license permits forking, so worst case we own a few hundred lines. Best case we delete our bespoke bootstrap code. Caveats: unproven externally, so pin the version, run it through our dependency and security review, pick one scope-registration style (attribute or code) and document it, and keep it out of production-critical paths until we have a quarter of internal usage behind it. Do not introduce it alongside Laravel's container in Laravel apps.