Laravel Route Linter Laravel Package

Product Decisions This Supports

• Route-hygiene as a quality gate: A route linter turns implicit team conventions (naming, verbs, parameter patterns, duplicate/shadowed definitions) into an enforceable, automatable check — a decision to treat routing as governed surface area rather than incidental config.
• Build vs. buy for internal tooling: The realistic alternative is a bespoke Artisan command or custom PHPStan/rector rule maintained in-house. Adopting this package is a bet that a small, single-purpose dependency is cheaper to own than an internal linter — a decision worth revisiting if the package stalls.
• Framework upgrade readiness: v1.2.0 adds Laravel 13 support. That makes the package a viable part of a Laravel 12 → 13 upgrade plan rather than a blocker, and it signals the maintainer is tracking framework releases. Conversely, any future lag here would force a "drop the linter or pin the framework" decision.
• API surface governance: Useful where routes are the product contract — versioned APIs, public webhooks, partner integrations. Linting catches accidental route renames, method changes, or collisions that would otherwise ship as breaking changes.
• Scoping and roadmap input: A lint report on the existing route table is a cheap, low-risk way to size "route cleanup / API consolidation" work before committing roadmap capacity to it.
• CI/PR policy: Supports a decision to add a route-lint step to CI and block merges on violations — a process change with near-zero runtime risk (dev-time only, no production footprint).

When to Consider This Package

Consider adoption when:

• You're on Laravel 12 or 13 (v1.2.0 is the release that makes 13 a supported target); older pins should stay on v1.1.x.
• The app has a meaningful route surface (roughly 50+ routes, or any versioned public API) and more than one or two contributors.
• You already run CI with static checks (Pint, PHPStan, tests) and want routing held to the same standard.
• You need guardrails against route collisions and shadowing — a class of bug that is cheap to introduce and expensive to debug in production.
• You want a non-invasive, dev-only dependency: no migrations, no service provider changes to your runtime path beyond registration.

Look elsewhere when:

• The app is small, single-developer, or has a stable, rarely-touched route file — the overhead outweighs the benefit.
• Your need is runtime route insight (usage, latency, traffic) rather than static rules — that's Laravel Pulse / Telescope / APM territory.
• You need security analysis of endpoints (auth coverage, IDOR, mass-assignment) — use a dedicated SAST or authorization-audit tool; a route linter is not that.
• A large share of your routes come from third-party packages you can't modify; lint noise from vendor routes will erode adoption.
• Supply-chain policy requires multiple maintainers or a vendor SLA. This is a single-maintainer, early-1.x package — acceptable for a dev-only lint step, not for anything load-bearing.

Caveat to carry into any evaluation: the 1.2.0 change is a single feature (Laravel 13 support), no breaking changes, no deprecations. Semver-compatible from 1.1.0. Confirm rule coverage and configuration ergonomics against a real branch before committing, since the release notes alone don't characterize the rule set.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, development-time tool that automatically checks our Laravel route definitions for mistakes and convention violations — duplicate paths, shadowed routes, inconsistent naming — before they reach production. It has no production runtime footprint and no infrastructure cost. The new v1.2.0 release adds support for Laravel 13, which keeps it usable through our next framework upgrade instead of forcing us to drop it or build our own. Cost is a few hours of integration into CI; the benefit is fewer production routing incidents and a cheaper, better-understood route/API cleanup when we choose to do one.

For engineering (bullets):

• Adds a static lint pass over route definitions — suitable for a CI step alongside Pint/PHPStan, failing PRs on violations.
• v1.2.0 is a minor, non-breaking release: the only change is Laravel 13 support. No migration work, no API changes, safe to bump from 1.1.0.
• Dev-only: no runtime middleware, no DB, no config publishing required for a first evaluation.
• Watch items: single maintainer and early-1.x maturity — evaluate rules on a real branch, expect to tune rule config to suppress noise from vendor-registered routes, and be prepared to fork or drop if framework support lags a future release.