Pretty Routes Laravel Package

Product Decisions This Supports

• Developer Experience (DX) roadmap: Informs whether to invest in internal developer tooling or lean on the community ecosystem. This package remains a ready-made, zero-build improvement to daily ergonomics in a Laravel app, and release 0.3.0 widens the gap between it and a bespoke internal tool: path/name exclusion and grouping are the kind of filtering logic teams otherwise hand-roll into shell scripts. It is a stronger "quick win" DX candidate than before, not a weaker one.
• Build vs. buy (adopt vs. build): Still an adopt vs. ignore decision rather than a build decision—native php artisan route:list is the baseline and this is an enhancement layer. But --group / --group-reverse and the multi-value name/path selector fix move it past "prettier output" into "queryable route inventory," which is meaningfully closer to the point where a team would otherwise write and maintain its own script. That raises the cost of ignoring it and lowers the incentive to build anything custom.
• Onboarding and knowledge transfer: A readable route table shortens time-to-mental-model for new engineers—naming conventions, middleware groups, controller/action mapping, prefix structure. Grouping now lets a new hire slice the surface area by domain (e.g. --group=prefix for an admin area) instead of reading one flat table, which supports decisions about onboarding docs, pairing sequences, and internal training material organized by subsystem rather than by monolith.
• Code review and architecture hygiene: This is where 0.3.0 changes the calculus most. Exclusion filters (--except-path, --except-name) let reviewers and auditors strip noise—health checks, vendor routes, debug endpoints—so route sprawl, duplicate URIs, inconsistent naming, and middleware misconfiguration stand out. Grouping exposes prefix/middleware clustering as a first-class view. This directly supports decisions about route organization standards, API surface governance, and whether to add a lightweight route-audit step to periodic hygiene reviews.
• Debugging and incident response: When a route isn't resolving or middleware isn't applying as expected, a clear and now filterable console view reduces time-to-diagnosis. The selector fix for multiple name/path values matters here—engineers can check several suspect routes in one command instead of iterating. Supports decisions about the team's standard debugging toolkit and whether to standardize it across squads.
• Dependency and maintenance policy: The maintenance signal has improved: this release ships CI (GitHub Actions) and issue templates, which are the cheapest credible evidence of an actively tended repository. That said, one release does not establish a track record—the prior assessment flagged a 2021-05-03 last release, so the decision this informs is whether to treat "recent release + CI" as sufficient evidence for a dev-only dependency, and whether to formalize a "dev-tools can lag, runtime deps cannot" policy with a defined staleness re-check cadence.
• Documentation and internal enablement: Whether to document recommended local dev commands in the README or developer handbook. With filtering options now available, the recommended-tooling entry becomes more useful—it can include concrete recipes ("audit only api/* routes," "exclude the health check") rather than a bare command name.

When to Consider This Package

Consider it when:

• Your team works in a Laravel codebase and engineers regularly run route:list during development, debugging, auditing, or onboarding.
• The route table is large enough that stock console output is hard to scan—many resources, nested prefixes, heavy middleware, or third-party packages injecting routes. This is now the strongest case for adoption: --except-path / --except-name remove vendor and infrastructure noise, and --group / --group-reverse make prefix- and middleware-shaped clustering legible. Native route:list has improved (JSON output, filtering by name/path/method, middleware and vendor flags), but it does not offer this grouping view.
• You want a low-effort DX improvement with no production footprint; it is a require-dev-style tool, so runtime and deployment risk are negligible.
• You're onboarding engineers new to Laravel or new to this application who need to build a mental model of the HTTP surface quickly—the grouping view is a genuinely better teaching artifact than a flat list.
• You have recurring route-audit or API-surface-governance needs but not enough of them to justify a purpose-built analyzer.
• You want to demonstrate momentum on developer productivity without allocating sprint capacity.

Look elsewhere or skip it when:

• Native parity is sufficient. If the built-in command's filtering already meets your readability bar, the delta is narrower than it was—the remaining differentiators are the grouping view and, partly, the exclusion filters. Verify against a real route table rather than assuming.
• You need programmatic route analysis. Still display-only. For machine-readable route data feeding CI checks, docs generation, or API contract testing, use the native JSON output or a purpose-built analyzer. Grouping a console table is not a substitute for an API contract tool.
• Maintenance risk remains a live concern. The new CI and issue templates are encouraging but early; there is still no long track record of prompt compatibility updates. Before adopting, validate against your current PHP and Laravel matrix and be prepared to drop it on upgrade. Treat it as a convenience, not a load-bearing tool.
• You have strict supply-chain or dependency-review policies. Even dev-only packages should clear your audit process; the low dependents count cuts both ways—small blast radius, but a small signal of ecosystem vetting.
• You need active support or SLAs. Still a community convenience utility with no vendor to escalate to.
• Your team's bottleneck isn't route visibility. Adding filters doesn't help a team that isn't running route:list in the first place; fix the workflow before adding tooling.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed developer tool that makes Laravel's route listing readable in the terminal. The latest release adds filtering and grouping, so engineers can look at a slice of the application—one domain, one middleware group—instead of the whole table. It has no runtime footprint: it ships as a development dependency and never touches production. Cost is effectively zero and risk is contained—if it stops working after a Laravel upgrade, engineers fall back to the built-in command and nothing breaks. It's a low-cost, reversible way to show investment in developer productivity and onboarding speed.

For engineering leadership: It's a single Artisan command that improves the daily debugging, review, and onboarding loop. No architectural commitment, no migration, no production surface. The new exclusion and grouping options are the substantive part of this release—they turn it from a pretty-printer into a lightweight route-audit tool, which is the difference between "nice to have" and "covers a gap we'd otherwise script." The project also added CI and issue templates, a modest but real signal that it's being maintained. Proposed next step: pin a version, validate against our current Laravel/PHP matrix in a short spike (roughly an hour), and document it as an optional local convenience. If native route:list already satisfies the team, we skip it—the downside is a deleted dev dependency.

For the engineering team: Version 0.3.0 adds --except-path, --except-name, --group, and --group-reverse, and fixes multiple values in the name and path selectors—so you can exclude vendor/health-check noise, pull several suspect routes in one command, and view routes clustered by prefix or middleware. Try it locally for a week on a real audit or debugging task. If it makes route review meaningfully faster, we'll add it to the recommended tooling list and the onboarding doc with a couple of concrete recipes. If the native command is good enough for your workflow, say so—that's a valid outcome and it saves us a dependency.