Laralint Laravel Package

Technical Evaluation

What this release is. glhd/laralint 0.2.0 is a single-change minor release adding Laravel 13 support. That is a compatibility-only signal: no new rules, no API surface change, no deprecations, no breaking changes called out. The material takeaway for a TPM is not the feature but the cadence — the maintainer is tracking an unreleased/upcoming Laravel major ahead of, or alongside, the framework's own release, which is the behavior you want from a dev-tooling dependency.

Architecture fit. Laralint is a development-time linting ruleset for Laravel codebases, not a runtime library. It sits in the require-dev layer alongside Pint/PHP-CS-Fixer/PHPStan and touches two surfaces: developer machines (pre-commit/editor) and CI (a lint job). It has no production runtime footprint, no database surface, no queue/worker interaction, and no request-path latency. Architectural risk is therefore confined to the delivery pipeline, not the application.

Integration feasibility. Low. Adoption is a composer require --dev plus a config file and a CI step. There is no service to provision, no credential, no data migration, and no consumer-facing change. The realistic effort is measured in hours for a first repo and a day or two to standardize across a fleet, dominated by triaging the initial violation backlog rather than by wiring.

Technical risk. Four things matter:

• Pre-1.0 versioning. At 0.x, semver does not protect you — a minor bump may carry breaking config or rule changes. Every upgrade should be treated as potentially breaking and pinned in composer.lock.
• Framework coupling. Laralint's value depends on internals of the Laravel version it targets. Adding Laravel 13 support means a version-support matrix now exists; the changelog does not state whether older majors (10/11/12) were retained or dropped, so the constraint set must be verified before adoption, not assumed.
• Churn as a failure mode. Lint rules that change between versions generate red builds unrelated to the author's commit. In a large team this is the single most common reason a linting tool gets muted or removed.
• Maintainer concentration. A single-maintainer, single-org package with a small release history is a bus-factor consideration for anything you make blocking in CI.

Key questions to resolve before committing:

1. Which engine does it wrap — Pint/PHP-CS-Fixer fixers, PHPStan/Larastan rules, or its own analyzer? This determines overlap with tooling you already run.
2. Is it report-only, autofixing, or both? Autofix scope determines blast radius.
3. Does it support per-rule toggles, path exclusions, and a baseline file for pre-existing violations?
4. What are the PHP and Laravel version constraints in 0.2.0, and were older Laravel majors dropped?
5. Is there a documented rule-change/deprecation policy, and how are rule additions communicated?
6. Runtime cost on a representative codebase — does it cache, parallelize, or support diff-only scanning?
7. License and security-reporting process; is there an internal owner willing to be the upgrade steward?

Integration Approach

Stack fit. Fits any Composer-managed Laravel application on PHP 8.x with an existing CI pipeline (GitHub Actions, GitLab CI, Bitbucket). It is complementary to — not a replacement for — Pint and static analysis: Pint normalizes style, static analysis catches type errors, laralint enforces Laravel-idiomatic patterns. Overlap must be confirmed (question 1 above); if it duplicates Pint fixers, adopt one or the other rather than both, to avoid two tools disagreeing on the same file.

Migration path. Purely additive and fully reversible. require-dev only, no production migration, no rollback plan needed beyond removing the CI step. The correct first step is a report-only run against the existing codebase to size the violation count — that number drives every subsequent decision about enforcement scope and timeline.

Compatibility. Verify the constraint set explicitly rather than inferring it from "adds Laravel 13 support." Two checks: (a) does 0.2.0 still satisfy your current Laravel major, and (b) does it require a PHP minor you are not yet on. Pin to an exact version ("glhd/laralint": "0.2.0") and upgrade deliberately with composer update glhd/laralint -W, reviewing the diff between rule output before and after.

Sequencing.

1. Spike (1 repo, 1 sprint): install report-only, run against a representative app, record violation count, runtime, and false-positive rate.
2. Triage: classify violations into genuine issues vs. stylistic noise. If noise dominates, stop here — the tool is not a fit.
3. Baseline: generate a baseline or exclusion list for legacy code so the build is green on day one.
4. Enforce on the diff: gate only new/changed files, so authors are never asked to fix code they didn't touch.
5. Standardize: roll the same config to remaining repos; publish a short internal doc.
6. Ratchet: periodically regenerate the baseline, shrinking legacy exceptions as files are touched.

Operational Impact

Maintenance. A dev-only dependency with an upgrade obligation that tracks Laravel majors plus occasional rule releases. Roughly one to two hours per upgrade cycle, concentrated on reviewing rule-output diffs. Pin the version; never float ^0.2. Assign a named owner — realistically the platform/developer-experience team, not individual product teams.

Support. Community OSS with no SLA. Escalation path is upstream issues/PRs; the same maintainer organization authored the package and the Laravel 13 support PR, which is encouraging but still a small team. Assume no guaranteed response time and plan accordingly: anything made blocking in CI must have an internal escape hatch (a documented "skip lint" label or a temporary exclusion) so a stale package can never trap a release.

Scaling. Cost scales with lines of code and repo count. On a monorepo, full-repo scans will dominate the lint job's wall time — mitigate with diff-only scanning, caching, or splitting the job per package. CI minutes are the primary consumable; estimate from the spike's runtime × pipeline frequency before a fleet-wide rollout.

Failure modes to design against.

• Upstream drift: a Laravel major or a laralint rule change turns CI red for unrelated reasons. Mitigation: pinned versions, diff-only gating, and an upgrade window decoupled from feature work.
• Abandonment: package stops tracking Laravel. Mitigation: because it is require-dev, removal is a one-line change — keep adoption shallow and avoid investing in a bespoke custom ruleset on top of it.
• Config drift: differing rule sets across repos produce inconsistent enforcement and erode trust. Mitigation: a single shared ruleset distributed from one source, not copy-pasted config.
• Autofix surprise: fixers rewriting code in unexpected ways. Mitigation: confirm autofix scope in the spike; run fixers as a separate, reviewable commit rather than inside the gate.
• Alert fatigue: high legacy violation volume leads developers to ignore output. Mitigation: baseline first, enforce second — never ship the tool red.

Ramp-up. Low. Developers already run Pint-style tooling, so the mental model is familiar; the incremental learning is the specific Laravel-idiom rules and the local fix command. Budget a brief internal note (how to run locally, how to read output, how to request an exclusion) plus one team briefing. No training course, no certification, no operational runbook beyond the CI job definition.

Assessment of this specific release. 0.2.0 warrants an initial baseline assessment rather than an update to a prior one, since none existed. The change itself is low-risk and additive; the meaningful signal is that the maintainer is proactively tracking Laravel 13. Recommended position: adopt in report-only mode on one repository this quarter, with enforcement contingent on the spike showing a low false-positive rate and a manageable baseline. Do not make it a blocking gate until the pre-1.0 versioning concern is retired by a 1.0 release or by six months of uneventful upgrades.