Pretty Routes Laravel Package

Getting Started

Pretty Routes is a thin, opinionated wrapper around route:list: it repackages the route table with grouped rows, colors, and controller/method separation so you can actually read it at a glance. Version 0.3.0 adds exclusion filters and configurable grouping, which moves it from "prettier route:list" to "a small route-reporting tool."

Install

composer require wulfheart/pretty_routes --dev

Publish the config if you want to tweak defaults:

php artisan vendor:publish --tag=pretty-routes-config

First command to run

php artisan route:pretty

There's no service to boot, no middleware, no runtime impact — the command is only registered in the console kernel.

Where to look first

1. php artisan route:pretty -h — the option surface changed in 0.3.0 (--except-path, --except-name, --group, --group-reverse). Confirm which ones your installed version actually supports before scripting against them.
2. config/pretty-routes.php — controls default column visibility, middleware display, and grouping behavior.
3. Compare against php artisan route:list on the same app for one or two runs so you understand exactly what Pretty Routes adds and what it drops.

First real use case: you inherit a Laravel app with 150+ routes and need to answer "which controller handles /admin/reports/export?" In native route:list that's a horizontal scroll. In route:pretty the grouped output lets you scan by URI prefix, with the controller action and middleware on the same readable row.

Implementation Patterns

Use it as a drop-in replacement in your daily loop. The package is dev-only and adds zero bundle cost. The realistic pattern is aliasing it in muscle memory:

# Instead of
php artisan route:list --path=api
# Reach for
php artisan route:pretty --path=api

The --path, --method, and --name filters mirror route:list, and since 0.3.0 they accept multiple values correctly. Any filter you already use in a shell script still works here.

Exclude noise instead of narrowing, when the noise is the problem. 0.3.0's --except-path and --except-name are the headline additions for real apps:

php artisan route:pretty \
  --except-path=_ignition \
  --except-path=horizon \
  --except-name=debugbar \
  --except-name=livewire

This is often better than --path= filtering because it keeps the whole application visible while removing the framework/package routes nobody is looking for. For a team-wide default, bake it into a composer script:

"scripts": {
    "routes": "php artisan route:pretty --except-path=_ignition --except-path=_debugbar --except-path=horizon --except-path=livewire"
}

That gives everyone one command that shows the app's actual surface, not the vendor surface.

Group by whatever the question is about. --group= lets you change what the blocks mean, and --group-reverse flips the sort order. Practical pairings:

# Who owns which URI area?
php artisan route:pretty --group=path

# Audit middleware exposure across the app
php artisan route:pretty --group=middleware

# Invert the ordering when the interesting routes sort last
php artisan route:pretty --group=controller --group-reverse

Check -h for the accepted values on your installed version — the option validates against a key list, so a typo fails fast rather than silently falling back.

Filter during feature work, not during review. When wiring a new module, keep a narrow filter running so the grouping stays tight:

php artisan route:pretty --path=admin/billing --method=POST

Grouping is most valuable when the set is small enough that the visual blocks mean something. On an unfiltered 400-route table the Pretty advantage largely evaporates — which is exactly why the exclusion flags matter.

Pair it with a diff-style check in CI logs. If you want the human-readable route table in a build artifact, force plain output so ANSI colors don't corrupt the log:

php artisan route:pretty --no-ansi > routes.txt

Colored output pasted into a GitHub Actions log renders as \e[32m garbage unless the terminal reports ANSI support — always pin --no-ansi for anything machine-consumed.

Use it for quick middleware audits. Because middleware renders inline with each grouped route, it's a fast way to answer "which routes aren't behind auth?" — group by middleware or filter by path and scan the column rather than grepping routes/web.php across files.

Combine with route:list for schema-changing work. Pretty Routes doesn't reliably reflect every new route type that route:list does (invokable controllers, closure routes, some resource shorthand on newer Laravel versions). During framework upgrades or route restructuring, verify with route:list --json — that output is the source of truth and is stable.

Gotchas and Tips

It is still a 2021-era package. 0.3.0 is the same generation as the releases before it — it targets the Laravel 8-era route:list command structure. On Laravel 9/10/11 it often still works because it wraps the underlying command, but do not assume it. Test on your actual framework version before adding it to a team workflow or CI step. Pin the package and verify after every major Laravel bump.

Multiple selector values now behave differently. Before 0.3.0, passing several --path or --name values was broken; the fix means those invocations now actually filter on every value. If you had a script that "worked" by relying on only the first value taking effect, it will now return a narrower result set after upgrading. Re-run your route scripts once after the bump rather than assuming identical output.

--except-* matches substrings, so be deliberate about scope. Excluding admin to hide a package's admin panel will also hide your own /admin routes. Prefer distinctive prefixes (_ignition, _debugbar, horizon, livewire) and confirm with a plain route:pretty diff before committing the filter to a shared script.

Newer route types may not render as expected. Invokable controllers, closure routes, and routes with enum-typed parameters added in recent Laravel versions can appear oddly grouped or miss columns because the formatting logic predates them. When the output looks wrong, cross-check with php artisan route:list --json before filing a bug — it's a formatting gap, not a routing problem.

The grouping is opinionated — but now adjustable. Default output is grouped by controller. If your app uses mostly closure routes or action classes, groups collapse into single-item blocks and the pretty formatting can look noisier than native output. Try --group=path or --group=name before giving up on it; if none of the grouping keys fit, route:list is the honest answer.

Colors vanish in CI, Docker, and IDE terminals — by design. Laravel's console component auto-detects TTY. Every non-interactive context (CI, docker exec without -t, output redirects) drops the color codes. If the output looks flat, that's expected; verify color separately in an interactive shell before concluding the install is broken.

Config caching can mask config edits. If you've published and edited config/pretty-routes.php during php artisan serve, Laravel may serve a cached config. Run php artisan config:clear after editing. Nothing Pretty-Routes-specific, but it explains "my config change did nothing" reports.

It's a dev dependency; do not deploy it. Require with --dev. If it slips into production composer.json, you're shipping a command nobody should run against prod and carrying a low-maintenance package in your production dependency graph. Run composer show wulfheart/pretty_routes in the target environment if you're unsure.

Extension points are minimal — that's fine. The package exposes a config file, column toggles, and CLI grouping flags, not a rendering plugin API. Don't try to customize output beyond that; if you need a custom route report (CSV, Markdown, custom columns), build it from Route::getRoutes() yourself. That's a ~30-line Artisan command and it'll outlive this package.

Maintenance signal is "alive but slow," not "supported." 0.3.0 adds issue templates and GitHub Actions, which is a good sign someone is still tending the repo — but the feature velocity and release cadence remain low, and there's no stated support window. Treat it as a frozen tool with occasional maintenance: validate compatibility on upgrade rather than expecting a fix on a timeline.