Laralint Laravel Package

Product Decisions This Supports

• Framework upgrade planning (Laravel 13 readiness): 0.2.0 explicitly adds Laravel 13 support. This is the single most decision-relevant fact in the release — it unblocks teams who want to move to Laravel 13 but have linting/CI gates pinned to this package. If Laravel 13 is on your roadmap, this release is a prerequisite checkbox, not a feature.
• Build vs. buy for static analysis / code standards: a package like this substitutes for a hand-rolled set of PHPStan/Pint/CS-fixer rules and bespoke CI scripts. The decision it informs is "do we adopt an opinionated, maintained ruleset, or do we own the rules and their maintenance?"
• CI quality-gate scope: determines whether lint enforcement sits in a shared pipeline stage across services, and therefore how much engineering time is reclaimed vs. how much rule-tuning debt you take on.
• Risk posture for a pre-1.0 dependency: at 0.2.0 the package is still 0.x, so the decision it supports is tolerance for churn — suitable for internal tooling and non-customer-facing repos, weaker for anything where a breaking change in the linter blocks a release.
• Roadmap signal: a maintainer shipping framework-version support promptly (0.1.1 → 0.2.0 within the project's early life) is evidence of active upkeep, which is the thing you're actually buying when you adopt a linter — the rules matter less than whether someone keeps them current.

When to Consider This Package

Consider adoption when:

• You have one or more Laravel applications or packages and want consistent, Laravel-aware static checks without authoring them yourself.
• Your team is planning or executing a Laravel 13 upgrade and needs the lint toolchain to keep pace with the framework — 0.2.0 specifically addresses this.
• You want a low-integration-cost CI gate: it's a Composer dev dependency, not a platform or SaaS, so there's no procurement, no data egress review, and no vendor lock-in beyond the rules themselves.
• You're standardizing conventions across multiple repos or a monorepo and want one shared, versioned source of truth.
• You have appetite for 0.x churn and can pin versions and absorb upgrades on your own cadence.

Look elsewhere when:

• You need guaranteed API stability / long-term support — 0.2.0 has no 1.0 signal. Prefer a mature standard (PHPStan, Larastan, Pint, Psalm) if stability is the priority; this package can complement, not replace, those.
• Your stack is not Laravel — the value is framework-aware rules; generic PHP projects gain little.
• Your team already has heavily customized in-house rules whose migration cost exceeds the benefit.
• You require documented rule coverage, security review, or a support contract — none of that is evident from a patch-level release note.
• You're on Laravel versions below the supported floor — the release notes only speak to the upper bound (13); verify the minimum supported version before committing.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source code-quality tool for our Laravel services. The 0.2.0 release adds support for Laravel 13, which matters because it removes a blocker from our framework upgrade path — without it, upgrading Laravel would have meant either dropping our lint checks or pausing to build replacements. It's a dev-only dependency: no license cost, no infrastructure, no customer-facing risk. The main caveat is maturity — it's still pre-1.0, so we'd pin the version and treat upgrades as a routine engineering task rather than assuming stability.

For engineering leadership: Adopt as a CI lint gate on Laravel repos where we don't already have bespoke rules; pin the version, budget a small amount of time per upgrade, and validate the minimum supported Laravel version against our oldest service. Expect it to complement — not replace — PHPStan/Larastan and Pint. Reassess at 1.0, or if release cadence stalls relative to Laravel majors.

For the engineering team: Low-risk, single-Composer-dependency addition. The real evaluation work is rule-fit: run it against one representative repo, review the volume and usefulness of findings before enabling as a blocking gate. Treat the 0.x version as a signal to pin and review changelogs on bump.