Laravel Utils Laravel Package

Technical Evaluation

Package: mll-lab/laravel-utils — v10.14.0 (released 2026-07-14) Change under review: New feature — "forbid string-keyed collection operations via PHPStan rules" (#41).

Architecture fit. This is a low-footprint Laravel utility package (helpers, collection/query conveniences, and now static-analysis rules). It sits at the periphery of the architecture — it does not own domain logic, routing, persistence, or auth — so adopting it does not constrain long-term design decisions. The v10.14.0 change reinforces that positioning: it is developer tooling, not runtime code. The new PHPStan rules are an opinionated quality gate that discourages string-keyed Collection access (e.g. $c['foo']) in favour of typed/property access, which pushes consumers toward generics-annotated collections that Larastan/PHPStan can actually verify. For teams already running Larastan, this is a natural extension of an existing practice rather than a new architectural commitment.

Integration feasibility. High. The change is additive and, per semver on a 10.x line, non-breaking: no runtime behaviour changes, no public API removal, no config publishing required for existing consumers who do not want the rule. Realistic effort to adopt:

• Add/verify phpstan/phpstan + larastan/larastan in require-dev.
• Register the package's ruleset (or individual rules) in phpstan.neon / phpstan.neon.dist.
• Run once across the codebase, baseline pre-existing violations, then ratchet to blocking in CI.

The main unknowns are mechanical: whether the rules ship as a ready-made ruleset (includes:) or must be registered rule-by-rule, and what PHPStan/Larastan version band is supported.

Technical risk. Low at runtime (zero production surface), moderate at the CI/delivery layer:

• A newly registered rule can surface a large violation count in a mature codebase, and if enabled as blocking in the same PR as the dependency bump, it stalls the pipeline and invites a rushed baseline that permanently hides the debt.
• Static-analysis version coupling is a known friction point: PHPStan, Larastan, and this package's rules must move together; a Larastan minor bump can change inferred types and flip rule results.
• False positives are plausible on legitimately dynamic keys (config-driven arrays, Arr helpers, JSON payloads), which creates pressure to suppress rather than fix.

Key questions for the maintainer/vendor:

1. Are the rules distributed as an includable ruleset, and are they opt-in or auto-applied?
2. Which PHPStan/Larastan versions are supported, and is that constraint declared in composer.json?
3. Do the rules target only generic-annotated collections, or all Collection/Eloquent\Collection usage?
4. Is there an escape hatch (ignore-by-identifier, inline suppression) documented?
5. What is the maintenance commitment behind the rules — is this a one-off or an actively curated ruleset?

Integration Approach

Stack fit. Assumes Laravel 10/11-era conventions and PHP 8.1+. It coexists with first-party tooling (Pint, PHPStan/Larastan, Pest/PHPUnit) without conflicting mandates, since it adds analysis rules rather than replacing a linter or formatter. Teams not running static analysis get nothing from v10.14.0 — for them this release is a no-op, which is acceptable but worth stating explicitly in the upgrade note.

Migration path.

1. Bump mll-lab/laravel-utils to ^10.14 in isolation; confirm no transitive resolution changes.
2. Add the rules to phpstan.neon in a separate PR from the version bump.
3. Generate a baseline or, preferably, scope the rule to new/changed files first.
4. Iterate to blocking once the violation count is stable.

Compatibility. No database, config, or published-asset changes; no cache clears or queue restarts. Downstream impact is limited to developer machines and CI runners. If the project pins PHPStan via a shared CI image, that image needs the new package version baked in — a coordination item, not a code change.

Sequencing.

• Now: evaluate in a throwaway branch at the target PHPStan level; measure violation count and CI delta.
• Next: adopt as non-blocking advisory output; triage false positives and file upstream if the rule misreads common Laravel patterns.
• Then: baseline and enforce for new code.
• Later: ratchet existing code opportunistically, tied to normal refactor work — not as a standalone cleanup epic.

Do not bundle this with a framework upgrade; static-analysis noise during a Laravel major bump makes real regressions harder to spot.

Operational Impact

Maintenance. Routine — dependency bumps on a normal cadence, with the caveat that PHPStan/Larastan/rule versions form a three-way compatibility triangle. Budget a small recurring task each time the analysis stack moves. Because the rules are dev-only, they never reach production and cannot cause runtime incidents.

Support. Open-source, small-maintainer package (MLL) with no commercial SLA. Responsiveness on rule-specific issues is the weak point: a false positive that blocks CI has no vendor escalation path, so the team needs an internal owner for the static-analysis configuration and a documented suppression procedure. That owner is the single most important operational control here.

Scaling. Negligible runtime scaling impact. CI cost grows with codebase size and PHPStan level, typically seconds-to-low-minutes; parallelise or cache the analysis result if the pipeline is already near its budget. The rule constrains how collections are accessed, which modestly improves type inference across large codebases — a mild long-term maintainability gain.

Failure modes.

• Pipeline blockage from a large unbaselined violation count — mitigate by phased rollout, non-blocking first.
• Silent erosion via blanket baselines or widespread ignore comments, converting a quality gate into decoration.
• Version-skew breakage where a Larastan bump changes inferred generics and flips rule outcomes — mitigate with locked versions and a scheduled upgrade window.
• False positives on dynamic keys leading developers to weaken types (casting to array) rather than fix access patterns — watch for this anti-pattern in review.

Ramp-up. Low. Roughly half a day for an engineer familiar with PHPStan to wire the ruleset and baseline; negligible for anyone already fluent in Larastan generics. The real onboarding cost is cultural — teams must understand why string-keyed collection access is discouraged, or they will suppress the rule rather than adopt the pattern. A short internal note with one good/bad example is sufficient.

Recommendation. Adopt the version bump; treat the new PHPStan rules as an independent, opt-in initiative with a phased non-blocking → blocking rollout and a named owner. Value is real but incremental, and entirely contingent on the team already investing in static analysis.