Weave Code
Laravel Route Linter Laravel Package
sinemacula/laravel-route-linter
A Laravel package for linting application routes. It inspects registered routes and flags common problems, helping you catch misconfigurations early and keep route definitions clean, consistent, and maintainable.
Lint your Laravel route table against RESTful URL conventions, with a CI-gating Artisan command.
Frequently asked questions about Laravel Route Linter
- How do I install sinemacula/laravel-route-linter?
- Install it as a dev dependency with composer require --dev sinemacula/laravel-route-linter. It is a development-time tooling package, so it should not be added to production requirements. After installation, invoke the package's Artisan command to lint your registered routes.
- Does laravel-route-linter support Laravel 13?
- Yes. Version 1.2.0 adds Laravel 13 support with no API, configuration, or CLI changes. Check the composer.json constraint before adopting, because widening the framework ceiling can sometimes quietly raise the minimum supported version. Confirm the release's CI matrix actually exercises Laravel 13 rather than only declaring support.
- What route problems does laravel-route-linter flag?
- It inspects Laravel's registered route table and flags common problems and deviations from RESTful URL conventions. The goal is to catch misconfigurations early and keep route definitions clean, consistent, and maintainable. It does not participate in request handling, so findings are reported at development or CI time.
- How do I run laravel-route-linter in CI?
- Add a pipeline step that invokes the package's Artisan lint command after dependencies are installed. Start in report-only mode against your current codebase to establish a baseline, triage genuine defects versus noise, and only then promote it to a blocking gate. Rollback is simply removing the dev dependency, with no schema or runtime coupling.
- Can I use laravel-route-linter with Laravel 11 or 12?
- Version 1.2.0 was released primarily to add Laravel 13 support, so teams on Laravel 11 or 12 gain no new linting capability. Before adopting, pin the version explicitly and verify the resolved Composer constraint still admits your framework major. If it does not, confirm that v1.1.0 remains installable for your applications.
- Does laravel-route-linter work with route caching enabled?
- The Laravel 13 release notes do not explicitly revalidate behaviour under route:cache, so treat this as something to test rather than assume. Many production-simulation CI stages enable route caching, so run the linter against a pipeline that mirrors that setup before making it blocking. Watch for edge cases around grouped, namespaced, and invokable controller routes.
- Is laravel-route-linter a dev dependency or a production dependency?
- It is a development-time tooling package, so install it with composer require --dev and keep it out of production builds. When deploying with composer install --no-dev, the package is absent from the deployable artifact. Consider asserting that in a build-time check so it never accidentally ships to production.
- How do I suppress or configure specific route lint rules?
- The package supports configuration so you can suppress noise and focus on actionable findings. Publish or edit the package config and adjust rule settings after triaging the baseline output. Run the linter in report-only mode first so pre-existing debt can be baselined rather than blocking the pipeline immediately.
- How does laravel-route-linter compare to Larastan or PHPStan?
- Larastan and PHPStan perform static analysis of PHP code, while laravel-route-linter inspects Laravel's registered route table for RESTful URL convention and route misconfiguration issues. The overlap is limited, so the marginal signal may still justify a pipeline stage. Evaluate its signal-to-noise ratio against your existing checks before promoting it to a blocking gate.
- Is laravel-route-linter actively maintained and safe to rely on in a CI gate?
- The v1.2.0 minor release adding Laravel 13 support indicates ongoing maintenance, but the package is maintained by a single maintainer, so bus factor is a real consideration for a CI gate. Pin the version, review release notes before upgrading, and keep a fallback plan such as report-only mode if the package stalls. Treat adoption of the linter and adoption of Laravel 13 as separate decisions.
Weaver
How can I help you explore Laravel packages today?