Container Laravel Package

Technical Evaluation

Architecture fit. The package is a standalone PSR-11 container, not a Laravel service provider or a replacement for Illuminate\Container. That distinction drives the entire assessment: it is architecturally compatible with a Laravel codebase (PSR-11 is the shared contract, and Laravel's container itself implements Psr\Container\ContainerInterface), but it is not additive to the framework's resolution graph. Realistic fit is narrow — internal CLI tools, Artisan-adjacent scripts, queue workers, and daemons inside the monorepo that today either bootstrap the full framework or hand-roll factories. The advertised differentiators (scopes, inflectors, explicit destruction) map directly to long-running process hygiene, which is precisely where Laravel's container is weakest: singletons resolved in a worker are never released, and there is no first-class scope boundary. Release 1.1.0 does not change this positioning; it refines how scopes are declared, which is a configuration-ergonomics change, not an architectural one.

Integration feasibility. Two viable patterns, both low-effort:

• Side-by-side: the CLI entrypoint builds this container and passes it explicitly; Laravel is never booted. Cleanest, lowest blast radius.
• Bridged: register Illuminate\Container as a delegate/fallback inside this container (or vice versa via a thin PSR-11 adapter) so framework-resolved services remain reachable. Adds a resolution seam that must be owned and tested.

Neither requires touching application service providers, which keeps the pilot reversible. The internal/ vendor namespace remains a metadata concern. The prior assessment flagged the 2026-09-08 release date as a probable scraping artifact; 1.1.0's changelog now carries that same date, which resolves the anomaly as a real tagged release rather than bad metadata — still worth confirming against our baseline clock, but no longer a red flag. Two new integration considerations arise from 1.1.0:

• Attribute-based scope declaration is a source-level coupling. #[ScopeShared] embeds a third-party class name into every annotated service. Unlike a wrapper interface, that coupling lives in domain files, so a future container swap requires editing annotated classes rather than one wrapper. If we adopt the attribute at all, it should be confined to CLI/worker-only classes.
• Scope configuration moves out of the composition root. The previous mitigation for bootstrap drift was a single shared binding manifest. Class-level attributes fragment that manifest across the codebase and make scope policy invisible in review. This is a real, if manageable, regression in governability.

Technical risk. Dominant risk remains provenance, not code. Zero stars, zero dependents, and no downstream ecosystem mean near-zero external validation: no third party has exercised this against PHP 8.3/8.4 edge cases, no CVE history to read. 1.1.0 does provide the first governance evidence we have — a public issue (#5), a merged PR, a commit SHA, and a semver-conformant minor bump from 1.0.1 — which mildly upgrades our read on upstream process from "assume zero" to "a functioning, if tiny, PR workflow exists." That is not validation; it is one data point. A single-maintainer bus factor plus an internal/ namespace still makes this effectively a source-drop dependency: adopt it and we are the maintainers. Secondary risks stand: reflection-based autowiring cost per resolution (still no documented compile/cache step), undefined behavior for union/intersection types and circular graphs, and destruction semantics that can invalidate instances still referenced elsewhere. The "quality badges" README change is cosmetic and should be read as zero signal on maintenance capacity. The 17.96 score and 63.89 opportunity score are unchanged; the capability gap is real, this artifact is still not safe.

Key questions.

1. Who owns this upstream, and is there a public commitment to semver and security response? (1.1.0 is a compliant minor bump — first weak positive.)
2. Is it a fork or derivative of PHP-DI / League\Container? If so, which behaviors diverge?
3. What exactly does "explicit destruction" do — invoke __destruct, drop references, or run a disposal callback? Is it idempotent and safe for shared instances?
4. Are scopes hierarchical (request/job scope nested under a process scope), and how are scoped singletons reset between jobs?
5. Revised. What is the actual minimum PHP version, and does "support PHP 8.1" mean 8.1 was previously broken or unsupported? Confirm 8.2–8.4 remain fully supported and that no 8.2+ syntax leaks into the 8.1 path.
6. Partly answered. #[ScopeShared] proves attribute support exists for scope declaration. Still open: attributes for contextual binding or injection targets, and programmatic equivalents for every attribute.
7. Resolved. The 2026-09-08 date is a genuine tag for 1.1.0, not stale metadata.
8. Is there any internal production user we can interview?
9. New. Is #[ScopeShared] inherited by subclasses, repeatable, and what is its precedence against a programmatic binding for the same class? Silent precedence conflicts are the highest-value unknown introduced here.
10. New. Can attributes be disabled or ignored globally (e.g. a container option), so we can lint them out of domain code while permitting them in CLI classes?

Integration Approach

Stack fit. Position it strictly as a CLI and worker runtime container, never as the application container. Laravel web requests keep Illuminate\Container untouched. The value proposition — scope boundaries and deterministic teardown — is only realized in processes that live longer than one request, so scope the adoption to Artisan commands, queue consumers, and scheduled daemons.

Migration path. Incremental, with an exit ramp at every step:

1. Vendor audit (1–2 days). Fork to our org, pin the 1.1.0 commit, read the full source (a lightweight container should be a few hundred lines), and confirm the destruction, scope, and attribute-resolution semantics from code rather than README. Determine the attribute precedence and inheritance rules. Record findings as the internal spec.
2. Spike (3–5 days). One non-critical CLI command rebuilt against the package, benchmarked against the current bootstrap for cold-start time and peak memory across N iterations.
3. Wrapper plus attribute policy. Introduce a first-party ContainerFactory interface in our shared internal package so call sites never type-hint the third-party class, and add a CI lint rule banning #[ScopeShared] outside an allow-listed CLI namespace. Register scopes programmatically in the binding manifest; treat the attribute as a convenience we deliberately do not spread. This is the single most important step — it converts a dependency decision into an implementation detail and preserves the swap-out option that attributes would otherwise erode.
4. Bridge (only if needed). A PSR-11 delegate so framework services are resolvable from CLI code without booting the full kernel.
5. Production, non-critical. One queue worker or reporting daemon, with a feature flag to fall back to the framework bootstrap.

Compatibility. Verify PSR-11 version alignment with psr/container already locked in composer.lock — a 2.0 vs 1.1 mismatch produces a signature error that surfaces only at runtime. Confirm the PHP constraint against our supported matrix (8.2–8.4) and pin down what the 8.1 claim implies about conditional code paths; a package that branches on PHP_VERSION_ID for attribute handling has more untested surface than one that does not. Confirm no ext-* or FFI assumptions. Because the package has no dependents, Composer's conflict graph gives us no safety net; treat composer update as a manual review event, and treat #[ScopeShared]-bearing classes as review-sensitive.

Sequencing. Audit → spike → wrapper + attribute policy → bridged pilot → single production surface → reassess. Two release-specific gates: verify the 1.0.1 → 1.1.0 diff is genuinely additive to our code paths (a scopes/attribute change can alter reset timing without an API break), and watch for 1.1.x/1.2.0 cadence as our only measure of upstream responsiveness. Gate the final step on two consecutive months of clean operation and on whether the wrapper could be reimplemented in-house at acceptable cost (likely yes, given the small surface — this is the real build-vs-buy question, and it should be answered before the pilot ships, not after).

Operational Impact

Maintenance. We inherit it. With no dependents and one apparent maintainer, upstream responsiveness is unverified; the merged PR in 1.1.0 is encouraging but insufficient. Budget for a named owner, a vendored fork, and a quarterly review of the diff against upstream. The wrapper keeps the fork cheap — but note that 1.1.0's attribute feature is the one thing that can make the exit expensive, by putting the dependency's class name inside our service classes. The lint rule in the migration plan exists specifically to keep the exit cheap; without it, the wrapper's value proposition degrades over time as engineers reach for the more ergonomic attribute.

Support. BSD-3-Clause is permissive and unproblematic for commercial use and modification. There is no security contact, no advisory feed, and no CVE history to monitor — our own dependency scanning must cover it. Realistic support posture: internal tier-3 only, with an escalation path that ends at "patch the fork." The 1.1.0 changelog format (conventional commits, issue and commit links) suggests the maintainer uses standard tooling, which slightly raises the odds of coherent upstream replies but does not constitute a support commitment.

Scaling. This is where the package earns consideration. Per-job scopes plus explicit destruction address the well-known worker memory creep caused by framework singletons that outlive their usefulness. Expect measurable reductions in resident memory for long-lived queue consumers — but validate with instrumentation, because reflection-based autowiring may trade memory for CPU on high-throughput workers, and attribute reflection adds a per-class cost at first resolution. Cap resolution depth, log container misses, and treat autowiring failures as startup errors rather than per-request exceptions. Warm up attribute-annotated classes in the same eager pass used for autowiring validation.

Failure modes.

• Autowiring ambiguity: untyped, union, or interface-only constructor parameters fail at resolution time, not at boot — mitigate with an eager-warmup pass in CI.
• Circular graphs: verify detect-and-throw rather than silent recursion or stack exhaustion.
• Stale scoped services: a scope not torn down between jobs leaks state across units of work — the most dangerous failure here, and silent.
• Over-eager destruction: disposing an instance still held elsewhere yields "used after destruction" bugs that only appear under concurrency.
• Bootstrap divergence: CLI and web resolving different implementations of the same interface becomes a config-drift class of bug; mitigate by sharing one binding manifest and by banning attribute-declared scopes outside CLI namespaces.
• New — attribute/binding precedence conflict: a #[ScopeShared] attribute and a programmatic binding disagreeing on sharing or scope, with the loser failing silently. This is the specific regression risk 1.1.0 introduces, and it is invisible in code review unless the binding manifest is checked against annotated classes.
• New — version skew on 8.1: if the attribute path is conditionally compiled or polyfilled for 8.1, our 8.2–8.4 runtime exercises a different code path than the one the feature was written for.

Ramp-up. Low technical, moderate organizational. The API surface is small, so engineers are productive in a day. The real cost is conceptual: the team must internalize scope boundaries and teardown rules that Laravel hides, plus a second container idiom coexisting with the framework's — and now a declarative attribute that makes the wrong pattern easier than the right one. Allocate a short internal write-up, one brown-bag session, and an explicit "register scopes in the manifest, not on the class" rule. Without it, engineers will both resolve framework services from the wrong container and scatter scope declarations across domain classes, creating the exact drift and lock-in described above.

TPM recommendation. Conditional pilot, no core adoption — unchanged by 1.1.0. The release is a clean, additive minor that answers one open question (attribute support exists) and mildly improves the governance signal (a real merged PR), but it does not touch the disqualifying factor: provenance and the absence of external validation. It also introduces one new, avoidable risk — source-level coupling via #[ScopeShared] and fragmented scope configuration — which we neutralize with a lint rule rather than adopt. Proceed only behind the wrapper, only on non-critical CLI/worker surfaces, and only with a named internal owner. Reassess after the pilot with a live build-vs-maintain comparison; the likely rational outcome remains to reimplement the ~500 lines of scope and destruction logic in-house rather than carry an unmaintained dependency.