Laravel Routes Core Laravel Package

Getting Started

composer require dragon-code/laravel-routes-core

Two facts shape how you use this. First, adoption is minimal — treat the package as source code you are adopting, not a framework with a community behind it; budget 15 minutes to read src/ end to end (a handful of small classes) and skim tests/, which in packages this size is the real documentation. Second, and this is the correction to older write-ups: the package is not frozen. Release 5.4.0 added Laravel 13 compatibility, so the illuminate/* constraints are being kept current against new framework majors. What it does not do is add features — 5.4.0's other changes are a logo, a banner, and a LICENSE year bump. Read it as maintenance-mode but alive: compat releases yes, new capability no.

Where to look first

1. composer.json — PHP and illuminate/* constraints. Still the single most important file: confirm the constraint actually admits your Laravel major (^13.0 from 5.4.0 onward) before you write any code.
2. src/ — the service provider (what gets bound, what gets published) and the base route-provider/registrar class.
3. tests/ — the canonical usage examples.
4. There is no meaningful README surface or community Q&A; do not plan on finding answers on Stack Overflow.

First use case

The package exists to remove boilerplate around loading and grouping route files — the chunk of RouteServiceProvider that every modular Laravel app rewrites: prefix, middleware stack, namespace, and require-ing routes/web.php / routes/api.php. If you are building a domain-modular app (or a package that ships its own routes) and you're tired of copy-pasting that block per module, this is the problem it solves. Start by wiring one module through it and comparing the resulting php artisan route:list output against your existing provider — if the URIs, names, and middleware columns are identical, migrate the rest incrementally.

Implementation Patterns

Per-module route providers. The natural pattern is one small provider per domain that extends the package's base route provider and declares only what differs — prefix, middleware, and route file paths. The base class handles the loadRoutesFrom/group mechanics. Keep these providers thin; if a module needs conditional logic (feature flags, tenant prefixes), put it in the provider's boot(), not in the route files.

Convention over configuration. Lean on a fixed file layout (routes/web.php, routes/api.php, routes/console.php) per module and let the provider discover them. The leverage here is that adding a module becomes: create directory, register provider. No edits to a central routing file.

Standard route-file shape. Regardless of what the base class does, the files it loads are ordinary Laravel route files, so use plain Laravel idioms inside them:

// app/Domain/Billing/routes/web.php
Route::prefix('billing')->name('billing.')->group(function () {
    Route::get('/', InvoiceController::class)->name('index');
    Route::get('/{invoice}', ShowInvoiceController::class)->name('show');
});

Package development. If you maintain your own Laravel package that ships routes, this is a reasonable thin dependency — MIT, small surface area, and now demonstrably tracking new Laravel majors. Pair it with dragon-code/laravel-route-actions if you're already in that ecosystem; the two are designed to compose.

Test the registration, not just the handlers. Add a test that asserts the routes actually exist and carry the right middleware, so a broken provider doesn't silently 404 in production:

$this->assertTrue(Route::has('billing.index'));
$this->assertContains('auth', Route::getRoutes()->getByName('billing.index')->gatherMiddleware());

Route caching discipline. Class-based route definitions (Route::get('/', InvoiceController::class)) and single-action invokable controllers cache cleanly. This matters more than usual here: if you adopt the package to reduce boilerplate, don't reintroduce closures in the route files, or php artisan route:cache will refuse to run.

Gotchas and Tips

Use a tight constraint, and keep the lock file. Full exact-pinning (1.0.0) is no longer necessary now that Laravel-major compat ships as a release, but stay tight ("5.4.*") rather than wide-open, and commit composer.lock. On every Laravel major, the first thing to check is whether a matching compat release exists; if the constraint is already ^13.0 you're fine, otherwise you either stay on the old Laravel or vendor the package.

Upgrading to 5.4.0 is a no-op unless you're on Laravel 13. No breaking changes, no new API, no deprecations — the release widens the framework constraint and touches cosmetic files. Don't schedule it as a feature upgrade; schedule it as the moment you become eligible for L13.

Provider ordering is your debugging lever. When routes appear with the wrong middleware or a prefix is missing, it's almost always boot order, not the package. Check bootstrap/providers.php (Laravel 11+) or config/app.php. php artisan route:list -v --path=billing shows the resolved middleware stack per route — far faster than reading the provider chain.

Name and URI collisions. Auto-registering routes per module is exactly the setup that produces duplicate route names, where the last one registered silently wins. Add a smoke test asserting count(Route::getRoutes()), or grep for duplicate ->name( values in CI. Prefix discipline (Route::prefix('billing')->name('billing.')) prevents most of this.

Stale config after changing anything. If the package publishes config or reads a config key, config:cache will happily serve the old value. php artisan config:clear && php artisan route:clear before you start debugging — you will otherwise chase a ghost.

Never edit vendor/. The extension point is subclassing the base provider (or binding your own implementation over the package's contract in a service provider). Because feature development is effectively dormant, any local patch is likely permanent and invisible — put overrides in your own class so a future vendoring or fork is a clean copy-paste.

Sanity-check the value proposition. For a single-app project, the honest read is that this package saves you roughly one RouteServiceProvider — maybe 60 lines. The real payoff is consistency across many modules or across several of your own packages. If you have one route file, skip it and write the standard Laravel provider; if you have eight domains, it earns its place. The 5.4.0 release lowers the ongoing-maintenance risk without changing that calculus.