jenssegers/lean
Lean is a lightweight Laravel/PHP package from Jens Segers that provides a simple, focused API for adding minimal functionality to your applications without extra overhead. Ideal for developers who want clean, easy-to-integrate tools.
Architecture fit. The evidence base does not describe a single artifact, and that is the first thing a TPM must resolve. The repository description and the v1.0.2 changelog (request->getAttribute resolved through method injection) describe a Slim 3 + league/container auto-wiring bridge. The marketing copy describes a lightweight Eloquent alternative that returns plain arrays on top of Laravel's query builder. These are different packages with different owners, different dependency graphs, and different failure modes. For a Laravel roadmap, the second reading is the one that matters — and on that reading, the fit is poor: Laravel ships a reflection-capable service container out of the box, so "auto-wiring as the core container" is a solved problem the framework already owns. On the Slim 3 reading, the fit is real but legacy-only, because Slim 4 made container injection native via AppFactory::setContainer(). Either way, this is not a forward-looking architectural component for a Laravel codebase.
Integration feasibility. Low-to-moderate, gated on identity confirmation. 31 stars, zero dependents, and a last release of 2019-01-14 mean there is no downstream evidence anyone has run this against a modern PHP/Laravel combination. There is no documentation beyond a one-line changelog; the source and tests are the specification. If the true requirement is a lighter read path than Eloquent, the honest baseline comparison is Laravel's own query builder (DB::table(...)->get()), which delivers plain arrays, no hydration, and zero new dependencies — a two-line spike that likely satisfies the requirement without adopting anything. If the true requirement is container auto-wiring, Laravel's container already resolves constructor type-hints, and league/container's own ReflectionContainer covers non-Laravel footprints.
Technical risk. High, concentrated in three places. First, identity risk: approving, budgeting, or roadmapping against the wrong package is the dominant failure mode here, and every downstream estimate is provisional until someone reads composer.json in the vendor directory and confirms what is actually installed. Second, abandonment risk: no release in six-plus years, no maintainer activity signal, no CI or coverage data supplied. A component on the resolution path of every controller is a bad place to carry unmaintained code. Third, version-drift risk: a 2019-era wrapper pins to league/container 1.x/2.x and slim/slim ^3.0; league/container 3.x+ changed registration and autowiring semantics, and PSR-7 bridge churn surfaces as Composer solve failures. PHP 8 reflection features — promoted constructor params, union types — are exactly the surface this code predates.
Key questions.
composer.json from the actual installed vendor directory?DB::table() against the Eloquent path on our real workload?Stack fit. Frame the decision as two separate requirements rather than one package. Requirement A — lighter read path: satisfied by Laravel's query builder with no new dependency; Lean::table('users')->where(...)->get() is a fluent API we already have under a different name. Requirement B — container auto-wiring: satisfied natively in Laravel, and satisfied in Slim 3 by handing (new ReflectionContainer())->cacheResolutions() to the app container. In both cases the package is optional at best and redundant at worst. A TPM should require the requesting engineer to state which requirement they actually have before any procurement or sprint capacity is allocated.
Migration path. If, after identity confirmation, this is the Slim 3 bridge and we are maintaining an existing Slim 3 footprint, the migration is a bounded swap: replace Pimple bindings with autowired constructor resolution, keep explicit bindings only at boundaries (interfaces, scalars, configured SDK clients). Sequence it as one isolated commit that deletes hand-rolled wiring, kept separate from any refactor, so rollback is a single revert. Before-and-after verification is mandatory — grep every $container->get() and assert each still resolves to the same concrete class, because reflection resolution fails later and occasionally succeeds with the wrong instance, unlike Pimple's loud boot-time failure.
Compatibility. Pin slim/slim to ^3.0 and league/container to the specific minor the wrapper was built against, and record why in the PR description. Run the package's own test suite on the target PHP before it touches a request path; a red run ends the discussion cheaply. Do not attempt a league/container major bump without treating it as a fork-and-patch project.
Sequencing. (1) Resolve identity — one hour, blocking. (2) Confirm framework and requirement — one day. (3) Timeboxed spike comparing the package against the framework-native alternative — two to three days, with a written exit criterion. (4) Only if the spike shows deleted boilerplate the team currently maintains: vendor or adopt with a named owner, pinned versions, and an isolated adoption commit. Anything that skips step 1 produces a plan built on a package that may not exist in the form assumed.
Explicit non-goal. Do not budget this as part of a Slim 4 or Laravel upgrade. Slim 4 makes it moot; Laravel never needed it. Presenting it as an upgrade enabler will mislead stakeholders.
Maintenance. The team becomes the maintenance plan. For roughly 200 lines of adapter that may be acceptable, but it must be a conscious, owned decision rather than a ticket comment. Concretely: vendor the fork if it touches a critical path, name an owner for the upgrade cadence, and record the pinned-version rationale. Without a named owner, the next engineer to bump PHP inherits an unplanned patch job under production pressure.
Support. Assume community support is nil. No vendor, no SLA, no issue-triage expectation, no documentation beyond a single changelog line from January 2019. Any incident involving this component is an internal debugging exercise against source. For a dependency sitting on the resolution path of every controller and service, that is a distinct risk class from a leaf utility library.
Scaling. Negligible throughput concern — dependency resolution is not a hot path multiplier, and caching reflections removes the obvious tax. The scaling risk is organizational, not computational: number of services, controllers, and new hires touching the container grows, and every one of them learns a bespoke resolution contract that no external documentation covers. That is an onboarding and bus-factor cost that compounds quietly.
Failure modes. Four to plan for. Silent-null attribute resolution: the v1.0.2 changelog does not state whether a missing request attribute throws or returns null. A null tenant ID silently widening a query is a data-leak-shaped bug wearing a convenience feature's clothes — test it explicitly, and if the package swallows it, add a guard middleware asserting required attributes before dispatch. Late resolution failures: reflection errors surface at request time, not boot time. Resolution-order collisions: route placeholders competing with middleware-set attributes of the same name, and validation layers running before attributes populate. Version drift: an unattended transitive bump breaking the wrapper's assumptions with no upstream warning.
Ramp-up. Low for an engineer who has read the source; effectively undefined for anyone relying on documentation. Budget the source read as the onboarding artifact: src/, then tests/, then the v1.0.2 tagged diff. If the package survives diligence, capture that read as an internal one-pager — otherwise institutional knowledge lives in one person's head.
Portfolio recommendation. Treat this as a defer / likely reject until identity is confirmed, and as a pin-and-own only in the narrow case of an active Slim 3 footprint with real bespoke container glue to delete. In a Laravel context, the defensible position is to decline adoption and point the requester at DB::table() for the read-path goal and the framework container for the auto-wiring goal — same outcomes, no new dependency, no maintenance liability, and no six-year-old unreleased code on the controller resolution path.
How can I help you explore Laravel packages today?