Lean Laravel Package

Product Decisions This Supports

• Build vs. buy on dependency-injection plumbing. The only verifiable value in this package is swapping Slim 3's default Pimple container for league/container with reflection-based auto-wiring. That is non-differentiating infrastructure — nothing a customer pays for, nothing a competitor copies. The default instinct should be to adopt rather than build, and this document is the artifact that either justifies adoption or justifies writing the ~200 lines in-house.

• A roadmap line you can actually ship: "middleware populates context, handlers declare it." v1.0.2 resolves request->getAttribute values through method injection, so request context (actor, tenant, locale, correlation ID, feature flags) arrives as typed handler signature parameters instead of $request->getAttribute('tenant_id') string lookups scattered across actions. This is a real DX and correctness improvement — typed parameters are greppable, refactorable, and visible in the signature. It is a roadmap item, not a refactor, and it costs one dependency.

• Architecture standardization. The container strategy is a near one-way door: whichever resolver you pick becomes the contract every service, new hire, and third-party integration learns. Decide deliberately now, because the cost of changing it later is every service definition in the codebase.

• Legacy-vs-greenfield scoping. The repository is explicitly a Slim 3 integration, and Slim 3 is a prior major line — Slim 4 (2019) made container injection a native AppFactory::setContainer() call. This is a maintenance-era dependency for an existing Slim 3 footprint, not a forward-looking pick for new services. A PM must know which side of that line the team is on before approving anything.

• Dependency portfolio hygiene: keep / pin / replace. 31 stars, 0 dependents, last release January 2019. Low adoption is not disqualifying for a narrow adapter, but it means you are the maintenance plan. That belongs in a portfolio review with a named owner and a review date, not buried in a ticket comment.

• The identity question — resolve before any of the above is binding. The evidence conflicts. The repository description says "use league/container with auto-wiring support as the core container in Slim 3." The marketing copy describes a lightweight Eloquent alternative returning plain arrays for Laravel. The release notes (request->getAttribute in method injection) match the Slim 3 reading. These cannot all be the same artifact. Do not approve adoption, budget migration work, or commit a roadmap line until someone confirms which package is in scope. Every estimate downstream of this section is provisional.

• If the Laravel reading is the real requirement, the product decision changes shape entirely: it becomes "should read-heavy endpoints (dashboards, exports, reporting, high-throughput list APIs) bypass Eloquent hydration and return plain arrays off the query builder?" That is a legitimate buy, with raw DB:: as the build alternative and lost accessors/casts/observers as the cost. But that artifact is not evidenced here — there are no releases, dependents, or changelog entries supporting it. Do not let the marketing copy carry a decision the repository cannot back.

When to Consider This Package

• Adopt when: you already run a Slim 3 application and are replacing bespoke container bootstrapping or a hand-rolled parameter resolver; auto-wiring would delete glue code your team currently maintains and reviews; middleware already populates request attributes and you want a first-class consumption path in handlers; and the pinned PHP and league/container constraints match your platform. Even then, be honest about the comparison: (new ReflectionContainer())->cacheResolutions() wired directly into the app container gets you most of this with one fewer dependency and a maintained upstream.

• Look elsewhere when: you are greenfield or mid-migration — land on Slim 4 and use AppFactory::setContainer() with league/container directly, or the framework's native container. Also look elsewhere if the actual requirement is a lightweight Eloquent alternative (different package entirely), if your handlers don't consume request attributes (the v1.0.2 feature is inert for you), if you need vendor support or an SLA, or if your platform has moved past the PHP and container versions this package targets.

• Diligence gate — identity first. Confirm which artifact is under evaluation, its intended framework, and whether it is still maintained. The entire evidence base is one patch-level changelog entry from 2019. No coverage data, CI status, maintainer activity, or downstream usage was provided.

• Health caveat and risk class. Assume community support is effectively nil. This component sits on the resolution path of every controller and service, so failure modes are app-wide, not local. Budget a source review, keep the adoption commit isolated so rollback is one revert, vendor the fork if it touches a critical path, and name an owner for the upgrade cadence in advance.

• One behavioural question that outranks the rest. When a required request attribute is missing — a middleware ordering bug, a route the middleware doesn't cover — does method injection yield null or throw? Nobody documented it. A silent null tenant is a data-leak-shaped bug wearing a convenience feature's clothes. If the package swallows it, add a guard middleware that asserts required attributes before dispatch, and treat that guard as part of the adoption cost.

How to Pitch It (Stakeholders)

To executives: This is a narrowly scoped plumbing library that, at best, removes custom glue code we would otherwise build and own — replacing bespoke container wiring and handler-parameter resolution with a small third-party dependency. The upside is a smaller maintenance surface and faster onboarding to a predictable wiring convention. The downside is real: a 2019-era component with negligible community adoption, sitting on the request path of every endpoint, which makes us the maintainers of last resort. The recommendation is not "adopt" or "reject" — it is a two-week, time-boxed evaluation that settles which package we're actually looking at, whether it removes measurable boilerplate, and whether it fails loudly on missing context. If those three answers are unsatisfactory, we stop, and the fallback is either one maintained library wired directly or a small in-house adapter we control.

To engineering: Treat the repository description as the source of truth — Slim 3 container bridge with auto-wiring — and verify the class names in src/ before writing code. The value proposition is one thing: delete the manual Pimple closures and let reflection resolve your own services, while you keep explicit bindings at the boundaries (interfaces, scalars, third-party clients). Pin league/container to the version this package was built against and record why in the PR. Run the package's own test suite on our target PHP first — this code predates PHP 8, and typed properties, union types, and promoted constructor params are exactly the surface reflection-based autowiring touches first. A red run ends the discussion cheaply. Finally, prove the v1.0.2 feature behaves under failure: deliberately omit the middleware that sets a required attribute and confirm you get an exception rather than a quietly wrong query.