Laravel Utils Laravel Package

Product Decisions This Supports

• Code-quality and standards enforcement: The v10.14.0 addition of PHPStan rules that forbid string-keyed collection operations lets engineering leadership treat static analysis as a first-class quality gate. PMs can point to this as a concrete example of shifting defect prevention into CI rather than code review or QA.
• Tech-debt and refactor scoping: If we choose to adopt the rule, every string-keyed collection operation in the codebase becomes an inventoried, trackable migration item. This directly informs backlog sizing, refactor roadmap, and the "how much legacy debt do we carry" conversation.
• Build vs. buy on internal tooling: Rather than writing bespoke PHPStan rules in-house, we can adopt an upstream, maintained rule. This reduces internal maintenance burden and lets us allocate engineering capacity to differentiation instead of lint infrastructure.
• API/data-contract design decisions: Forbidding string keys nudges the codebase toward typed keys (e.g., backed enums or integer keys), which is a product-relevant signal about how we model configuration, localization, and dynamic attributes. It affects how we document and evolve data contracts.
• Roadmap input on Laravel/PHP modernization: Adoption signals alignment with a modern, statically-checked PHP toolchain, relevant to planning upgrades, hiring, and platform strategy.

When to Consider This Package

Consider adopting when:

• You run Laravel with PHPStan already in CI and want stronger, opinionated rules for collection usage.
• Your team has (or is moving toward) typed keys — enums, integer keys — and wants static enforcement rather than convention.
• You maintain a shared library or platform layer where consistent utilities reduce duplication.
• You want low-cost, upstream-maintained lint rules instead of custom scripts.

Look elsewhere or defer when:

• Your codebase is heavily string-keyed by design (e.g., localization arrays keyed by locale) and adopting the rule would create a large one-time migration with unclear user value.
• Your team has no PHPStan baseline; the marginal value of this specific rule is low until the practice exists.
• You prefer first-party Laravel conventions and a minimal dependency footprint — this is a community utility, not official Laravel tooling.
• The rule's value depends on enforcement discipline; without CI gating, adoption yields little.

How to Pitch It (Stakeholders)

For executives: A small, low-risk enhancement to our PHP tooling that converts a class of subtle bugs (string-keyed collection mistakes) into build-time failures instead of production incidents. It is free, upstream-maintained, and reduces internal tooling work — a quality improvement with near-zero cost and no user-facing change.

For engineering: This release ships a PHPStan rule that flags string-keyed collection operations, letting us encode a design preference as an automated check. It complements existing static analysis rather than replacing it. Adoption is optional and can be staged: enable the rule in warn mode, measure the violation count, then decide whether to enforce in CI. Expect an initial inventory cost if the codebase has many string-keyed operations; that inventory doubles as a refactor estimate.