Routing Tools Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — the day-to-day value is for developers maintaining Symfony 3.4/4.x applications. If you're a Laravel developer, treat it as a reference implementation of routing conventions rather than something you composer require into a Laravel app; there is no service provider and it will not auto-discover.

Minimum steps in a Symfony app:

1. Install with an explicit constraint (the last tagged release is from 2018-07-05, so pin it):

   composer require ruwork/routing-tools-bundle:^0.1
   

2. Register the bundle in config/bundles.php:

   return [
       // ...
       Ruwork\RoutingToolsBundle\RuworkRoutingToolsBundle::class => ['all' => true],
   ];
   

3. Read the repository README before writing code. This bundle is archived with zero dependents and no recent releases; the README is the only authoritative source for which services and helpers are exposed in the version you pulled.
4. Run bin/console debug:router and bin/console debug:container --tag=routing.loader to confirm the bundle's loader/decorators actually registered.

First use case: you have a Symfony app with hand-written route names that are inconsistent and easy to typo, and you want route names/URL generation to be derived consistently so that redirectToRoute() and Twig path() calls stay honest. That is the sweet spot for a "routing tools" bundle — it wraps or decorates Symfony's router so generating a URL for a controller action is a single, named call instead of a memorized string.

If the exposed API doesn't match what you need on day one, stop there. An archived routing bundle is not worth adapting; copy the ~100 lines of logic you actually use into your own App\Routing namespace.

Implementation Patterns

Route naming as the integration contract. The core pattern with a routing-tools bundle is: define routes once (YAML/attribute/PHP), then always generate URLs through the bundle's helper or through the standard RouterInterface — never by concatenating strings. This mirrors Laravel's route('users.show', $user) and is the habit worth porting over either way.

Controller-centric redirects. The most common daily call is "redirect to the action I just handled." In a Symfony controller this is:

return $this->redirectToRoute('app_user_show', ['id' => $user->getId()]);

If the bundle provides a router decorator or a controller trait, use it consistently in one place (a base AbstractController) rather than sprinkling it across controllers, so a future replacement is a one-file change.

Twig stays on path()/url(). Don't invent a parallel template helper. Whatever the bundle exposes should resolve to the same route names that path() understands; if it doesn't, the abstraction is leaking and you'll get RouteNotFoundException at render time instead of at boot.

Testing as the safety net. Routing tools are exactly the kind of thing that silently breaks on a Symfony minor bump. Add a smoke test that boots the kernel and asserts URL generation:

public function testRouteGeneration(): void
{
    self::bootKernel();
    $router = self::getContainer()->get('router');
    $this->assertSame('/users/1', $router->generate('app_user_show', ['id' => 1]));
}

Cache is part of the workflow. After touching routing config or the bundle's compiler passes:

bin/console cache:clear && bin/console debug:router

Route collections are compiled; a stale cache will make you think the bundle is broken when it isn't.

Laravel developers: map the concepts and move on — Route::name() ≈ route name: in Symfony, route() ≈ generate(), redirect()->route() ≈ redirectToRoute(). Nothing here replaces Laravel's router; the architectural takeaway is keeping route names centralized and typed.

Gotchas and Tips

• Archived and unmaintained. Last release 2018, zero stars, zero dependents. There will be no fixes for Symfony 5/6/7 incompatibilities (typed container interfaces, RouteCollectionBuilder removal, ContainerAwareInterface deprecation). Budget a fork or an inline copy.
• Compatibility cliff. Symfony 4.2+ deprecated several routing APIs this bundle likely touches. Check composer why-not symfony/framework-bundle immediately after install; don't assume ^4.0 resolves cleanly.
• Bundle registration order matters. Routing decorators must be registered after FrameworkBundle; putting this first in bundles.php can leave you with the default router instead of the decorated one. Verify with debug:container router.
• Silent fallbacks. Router decorators that fail to compile often just fall through to Symfony's default router, so everything "works" while your tools are inert. The only reliable check is debug:router plus a generation test.
• Route name collisions. Auto-generated names derived from controller FQCN/method can clash with existing YAML route names, and Symfony resolves the first match — no error. Grep your route configs for names before enabling generation.
• Debugging: bin/console debug:router --show-controllers to see the loader's output, bin/console debug:router <name> for one route, and -vvv on cache:clear to catch compiler pass exceptions that get swallowed.
• Extension point that actually matters: Symfony's routing.loader tag. If you need custom behavior (locale-aware routes, controller-derived names), write your own loader and register it with that tag rather than extending an abandoned bundle — you'll get the same result with a supported dependency graph.
• License is MIT, so forking into your own App\RoutingToolsBundle is legally clean. That's the realistic path for anyone evaluating this today.