Laravel Laroute Laravel Package

Getting Started

This is a thin extension of aaronlord/laroute, so everything you know about the base package applies; the fork only changes how routes are collected/rendered. Treat the base package's docs as your primary reference and diff the fork's src/ against it.

Install and confirm what you got

composer require axn/laravel-laroute

Because the package is archived and has almost no downstream usage, verify before writing code against it:

1. vendor/axn/laravel-laroute/composer.json — check the require block for the Laravel version constraint and whether it pulls aaronlord/laroute in as a dependency or replaces it.
2. vendor/axn/laravel-laroute/src/ — find the service provider class name (the fork may keep the Aaronlord\Laroute namespace or use its own). That name is what you pass to vendor:publish and, on pre-5.5 apps, what you register in config/app.php.
3. README.md — look specifically for what the fork adds (extra filters, template variables, parameter handling). That delta is the only reason to choose this over the upstream package.

Publish the config and generate once

php artisan vendor:publish --provider="<ProviderFromSrc>"
php artisan laroute:generate

The inherited command writes a JavaScript file (by default under public/js/laroute.js) that exposes a global laroute object. The config file — output path, JS namespace, and route filters — is where 90% of your day-to-day tuning happens, so read it first.

First use case

Load the generated file in your layout and replace a hardcoded URL:

<script src="{{ asset('js/laroute.js') }}"></script>

// before: fetch('/users/5/edit')
fetch(laroute.route('users.edit', { user: 5 }));

That's the whole value proposition: named routes stay the single source of truth, and JavaScript stops hardcoding paths that break when you rename a URI.

Implementation Patterns

Blade stays server-side, JS gets the bridge. Don't try to replace route() in Blade. Use the generated helper only in inline scripts, Alpine/Vue components, and standalone .js files. A clean split:

<a href="{{ route('users.edit', $user) }}">Edit</a>

<script>
  window.routes = {
    usersIndex: "{{ route('users.index') }}", // fine for one-offs
  };
</script>

…and reserve laroute.route() for code paths where you can't interpolate Blade (AJAX handlers, dynamically built table rows, modals).

Build URLs from data, not strings. The common pattern in list/detail UIs:

async function loadUser(id) {
  const res = await fetch(laroute.route('api.users.show', { user: id }), {
    headers: { Accept: 'application/json' },
  });
  return res.json();
}

Pass parameters as an object keyed by the route parameter name ({user: id}), not positional order — positional arrays work but silently break the moment someone reorders {user}/{tab}.

Wire generation into your pipeline. The file is a build artifact; regenerate it whenever routes change. Add it to your deploy script rather than committing it:

"scripts": {
  "post-autoload-dump": [
    "@php artisan laroute:generate"
  ]
}

In local dev, either run it manually after touching routes/*.php or add a file watcher (Vite plugin, nodemon, or a simple watch task) — stale generated files are the #1 source of "the route exists but JS says undefined."

Filter aggressively. If the config supports prefix/name filters, restrict output to the routes the frontend actually needs. Shipping your entire admin route table to the browser is both a payload problem and needless information disclosure.

Custom template as the extension point. The base package renders through a JS template you can override in config. This is where you add project-wide helpers — appending query strings, prefixing a base path for subdirectory deployments, or wrapping route() in a try/catch that logs missing names in dev:

route: function (name, params) {
  if (!this.routes[name]) {
    if (window.APP_DEBUG) console.error('Unknown route:', name);
    return '#';
  }
  // ...template's default logic
}

Framework integration. In Vue/React, either expose it via window.laroute and import the generated file once in your entry point, or configure your bundler's externals so laroute resolves to the global. Don't import the generated file from multiple entry points — you'll bundle duplicate copies.

Gotchas and Tips

Archived means you own the maintenance. Last release March 2022, 6 stars, 6 dependents. Before adopting, test against your Laravel version specifically — route collection internals (Route::getRoutes(), getAction(), compiled route objects) have shifted across 9/10/11. If it breaks, vendor the package or fork it; don't expect upstream fixes.

Route caching order matters. Run php artisan route:cache before laroute:generate in deployments if your filters inspect route groups or middleware, since those are only fully resolved once routes are loaded normally. And clear config cache after editing config/laroute.php:

php artisan config:clear && php artisan laroute:generate

Unnamed and closure routes are invisible. Only named routes make it into the file. If a route is missing, check for a missing ->name() before debugging the generator.

Optional and wildcard parameters. Optional segments ({tab?}), route defaults, and wildcards ({path} where .* is allowed) render inconsistently — the JS side just substitutes strings. Test these explicitly; if they misbehave, encode the value yourself or keep those routes out of the generated set.

Encoding. Parameter values are substituted as-is by the template. URL-encode user-supplied values that can contain /, ?, #, or spaces, or they'll corrupt the path.

Subdomains and subdirectory deployments. Generated paths are typically relative. If the app lives under https://example.com/app/, or routes are defined on a subdomain, the generated URL may be wrong. Fix it in the template (prepend a base) or in config — don't patch call sites.

Generated file caching. The output filename is static, so browsers will happily serve a stale copy. Add a cache-busting query (?v={{ filemtime(public_path('js/laroute.js')) }}) or generate into a hashed filename as part of your asset build.

CI/deploy permissions. The generator writes into public/. In containerized deploys, generate during the build stage (where the filesystem is writable) and copy the result forward, rather than running it at runtime as an unprivileged user.

Debugging checklist when laroute.route(...) is undefined or returns a bad path:

1. Is the <script> tag actually present and returning 200?
2. Does the generated file contain your route name? (grep users.edit public/js/laroute.js)
3. Did a filter exclude it?
4. Was the file generated after the route was added?
5. Is another global named laroute clobbering it?

It is not authorization. The generated file exposes route names and URI patterns only, but if you filter by nothing you're publishing your whole route map. Never treat a URL being absent from the file as access control — middleware still does that job.