Routes Explorer Laravel Package

Getting Started

Install as a dev dependency so it never ships to production:

composer require infyomlabs/laravel-routes-explorer --dev

The service provider (InfyOm\RoutesExplorer\RoutesExplorerServiceProvider) is auto-discovered via package discovery. Publish the config to see exactly where the explorer route is mounted and which middleware wraps it:

php artisan vendor:publish --provider="InfyOm\RoutesExplorer\RoutesExplorerServiceProvider"

Open config/routes-explorer.php, note the URI/path and middleware, then start php artisan serve and visit that path (commonly /routes-explorer). Confirm it registered with:

php artisan route:list --path=routes-explorer

First use case: onboarding to an unfamiliar or large codebase. Instead of scrolling php artisan route:list output, load the explorer and get a browsable table of every verb/URI/name/action/middleware tuple — useful when a bug report says "the /admin/foo endpoint returns 403" and you need to trace it to a controller and middleware stack in seconds.

Implementation Patterns

• Environment-scoped registration. Keep the package in require-dev and only register the provider in local/staging. If you need it in staging, gate it behind your existing auth middleware rather than relying on the package's defaults.
• Middleware auditing workflow. The most valuable day-to-day use is filtering by middleware to answer "which routes are not behind auth?" Sort/filter the middleware column to spot unprotected endpoints before a security review, then cross-check with php artisan route:list --except-vendor.
• Named-route cleanup. Filter by route name prefix to find orphans, inconsistent naming (admin.users.index vs users.admin.index), or routes that never got a name. Pair with a static grep for route( calls to find dead routes.
• Controller/action inventory. When refactoring a fat controller, filter by controller class to see every action still reachable from HTTP. This is a fast way to find methods that exist but aren't wired to any route.
• API vs web separation. Filter by URI prefix (api/) or by the api middleware group to audit a large API surface without the noise of web routes.
• Custom views. Publish the views (php artisan vendor:publish --tag=..., check the provider for tags) and add columns you care about — e.g., a "deprecated" flag, or a link into your APM tool. The explorer is essentially a table over Route::getRoutes(), so extending the Blade view is the cheapest extension point.
• Pair with route:list for scripting. The explorer is interactive; for CI checks (e.g., "fail if any route lacks auth"), use php artisan route:list --json in a test instead. Treat the explorer as the human-facing view and route:list as the machine-facing one.

Gotchas and Tips

• No built-in auth. The package is a debugging UI; it will happily expose your full route map (including middleware and controller FQCNs) to anyone who can reach the URL. Always restrict by environment and middleware. Double-check it doesn't leak into APP_ENV=production after a deploy config drift.

• Old release (Feb 2022). Verify compatibility with your Laravel version before relying on it. If auto-discovery fails or the provider throws, register it manually in config/app.php (or bootstrap/providers.php on Laravel 11) conditionally:

  if (app()->environment('local')) {
      $app->register(\InfyOm\RoutesExplorer\RoutesExplorerServiceProvider::class);
  }
  

• Route caching. The explorer reads the live route collection; when routes are cached (php artisan route:cache) the data reflects the cache. If entries look stale after adding a route, run php artisan route:clear before trusting the view.

• Large apps render slowly. Thousands of routes can make the table sluggish — there's no pagination guarantee. The fastest workaround is a narrower use case: query php artisan route:list --path=... rather than eyeballing the full list.

• Debugging registration. If the URL 404s: confirm the provider is loaded (php artisan about), confirm the route exists (php artisan route:list --path=), and check whether a catch-all route or a Route::fallback in your app is shadowing it. Publishing the config and changing the path is the quickest fix when it collides with an app route.

• Extension points, in order of least friction: config (path/middleware) → published views → your own controller that reuses Route::getRoutes(). Forking the package is rarely worth it; the underlying API is a one-liner, so if you outgrow the package, replacing it with a small custom controller is often cleaner than fighting an unmaintained dependency.

• Don't commit it as a hard dependency. With zero dependents and a two-year-old release, treat it as a disposable dev tool: safe to install locally, risky to bake into CI or shared tooling.