xiian/bundleroute
Bundleroute is a Laravel package for organizing and bundling route definitions into reusable groups, keeping route files tidy and easier to maintain in existing applications.
BundleRoute lives in the route-organisation layer of a Laravel app: it lets you declare a set of routes as a named bundle (usually backed by its own route file) and register that bundle in one call, so routes/web.php and routes/api.php stop turning into thousand-line catch-alls.
composer require xiian/bundleroute. Release 1.1 is a minor bump on the 1.0 line, so code against the API documented in the README — nothing in the notes signals a breaking change, but nothing documents a new feature either (see Gotchas).php artisan vendor:publish (filter for the BundleRoute service provider) and read it top to bottom before writing any routes — this is where defaults for prefixes, middleware, and naming usually live.tests/ (the fastest source of truth for intended behaviour in a thinly-documented package).routes/admin.php is a good candidate — and move it behind a bundle without changing any URI, middleware, or name. Then verify parity: run php artisan route:list before and after and diff the output. If the two are byte-identical, the bundle is wired correctly and you can migrate the remaining files with confidence.Bundle per domain, not per file size. Group routes that share a middleware stack and URI prefix (admin, account, webhooks, an API version). Bundles that cut across auth boundaries force you to re-specify middleware per route, which defeats the point.
Push shared attributes to the bundle boundary. Prefix, middleware, and name prefix belong on the bundle registration; per-route declarations should be the exception. When a single route inside a bundle needs different middleware, prefer ->withoutMiddleware() on that route over splitting the bundle.
Register from a service provider, not from routes/web.php. Bundles registered in boot() compose predictably with other packages and survive route caching. Registration order matters: bundles that depend on middleware aliases or route-model bindings registered by other providers should come after them.
Ship it through the deploy pipeline. Any route-registration package interacts with php artisan route:cache, so add the cache step to your deployment script and confirm the app boots with the cached routes, not just in php artisan serve.
Test at the bundle level. One feature test per bundle covering "a representative route resolves, hits the right controller, and passes/fails the expected middleware" catches almost all wiring mistakes far cheaper than exercising every route.
Keep local and production symmetric. If a bundle is conditionally registered (feature flag, environment check), ensure the flag is resolved at boot in both environments — otherwise route:list locally and the cached routes in production diverge silently.
1.0...1.1 diff, skim it for touched boot/registration code, and run your route test suite plus a route:list snapshot diff before bumping in production. Pin ^1.1 and let the diff — not the version number — decide whether it's a drop-in.route:cache is the usual failure mode. New bundles won't appear until the cache is cleared (php artisan route:clear), and closures or non-serialisable route definitions inside a bundle will make route:cache fail loudly. Run php artisan route:cache locally before every deploy that touches routing.admin. name prefix produce duplicate route names; Laravel keeps the last one registered. php artisan route:list --name=admin. is the quick audit.SubstituteBindings runs, or bound models will resolve against the wrong scope.php artisan config:cache will freeze bundle settings; a config change without a re-cache is the classic "it works locally" report.boot()/register() (conditional or environment-specific bundles), and route macros on the router if the package exposes them — those three cover nearly every customisation without forking.How can I help you explore Laravel packages today?