Php Utils Laravel Package

Product Decisions This Supports

• Engineering standards as a product-quality lever. This package is primarily a rules and utilities toolkit that encodes "how we write PHP" (PHPStan disallowed-call rules, shared rules.neon, helper utilities). For a PM, it's the cheapest mechanism to make code-quality expectations enforceable in CI rather than aspirational in a wiki.
• Roadmap input: upgrade windows vs. feature work. v7.0.0 is a breaking release (drops spaze/phpstan-disallowed-calls ^2, requires ^4.4). This is not a user-facing feature, but it consumes engineering capacity and can block pipelines. PMs should treat tooling-major upgrades as scheduled maintenance items with an owner and a date, not as background noise.
• Build vs. buy for internal tooling. The existence of a maintained internal/community package for lint rules and static analysis means the team should not be hand-rolling per-repo PHPStan configs. Standardize on one source of truth; the marginal cost of divergence (inconsistent reviews, duplicated rule debates) is higher than the cost of upgrading.
• Code-review and onboarding load. Banning a construct centrally (here: CarbonImmutable via PHPStan, #80) removes a recurring review argument and prevents a class of date/time bugs from being reintroduced. That is a measurable reduction in review churn and a faster ramp for new engineers.
• Risk/compliance posture. Banned-call rules are a lightweight policy engine — useful if you need to demonstrate that unsafe functions (eval, exec, unvetted shell calls, raw date handling) cannot enter the codebase. Supports security-questionnaire and audit answers with evidence rather than assertion.
• CI matrix decisions. The release notes expose a real constraint: on PHP 8.0, spaze ^4.4 requires phpstan ^1.12.6, which conflicts with larastan 1.0.4 (phpstan <1.9). This forces a product-adjacent decision: keep PHP 8.0 in the support matrix and lose the rule set there, or drop PHP 8.0 and gain uniform enforcement. That's a support-policy call with customer-facing consequences if any deployment target is still on 8.0.

When to Consider This Package

• Adopt when you maintain multiple PHP/Laravel repositories and want one shared, versioned source of coding rules and small utilities, and you already run PHPStan in CI.
• Adopt when the team's pain is consistency, not capability: repeated review comments about date/time handling, disallowed functions, or style drift across repos.
• Adopt when you want rule changes to ship as a versioned dependency upgrade (auditable, revertable) instead of as a cross-repo config edit.
• Look elsewhere / defer when you're on PHP 8.0 with Larastan 1.0.x — v7.0.0 explicitly drops rule loading in that CI configuration. Staying on v6.16.0 is reasonable there, but you must accept that the new CarbonImmutable ban and future rules won't apply to that lane.
• Look elsewhere when you need application-level functionality. This is development-time tooling; it delivers no runtime product value and should never compete with feature work for the same budget line.
• Look elsewhere when the organization is small enough that a single repo's phpstan.neon and a short style guide suffice — the coordination overhead of a shared package outweighs the benefit.

How to Pitch It (Stakeholders)

For executives: This is infrastructure for code quality, not a product feature. It lets us define rules once — including a new rule preventing a date/time class we've had bugs with — and have every repository enforce them automatically in CI. The cost is a one-time major upgrade this cycle; the return is fewer defects, less review back-and-forth, and a defensible answer to "how do you enforce standards?" The main decision requested is a support-policy call: whether to keep PHP 8.0 in our matrix, since the new static-analysis dependency can't coexist with our older Larastan version on 8.0.

For engineering: v7.0.0 is breaking — bump spaze/phpstan-disallowed-calls to ^4.4 and confirm your PHPStan/Larastan pairing before upgrading. Rule inclusion is now keyed on whether spaze is installed, not on PHP version, so CI lanes without it behave predictably. Payoff: CarbonImmutable is now banned via PHPStan (#80), closing a recurring class of inconsistency. Upgrade path is a dependency bump plus a CI matrix check; expect low code churn and no runtime impact.

Ask: approve the upgrade as a scheduled maintenance item with a named owner, and make an explicit decision on PHP 8.0 support so enforcement isn't silently uneven across repos.