Jsrouting Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony2 bundle, not a Laravel package. There is no service provider, no auto-discovery, no config/app.php entry. If you are coming from Laravel, the closest mental model is Tighten's Ziggy — it exposes named routes to JavaScript so you stop hand-concatenating URLs in front-end code. The concept transfers; the code does not. Expect to do the wiring the Symfony2 way (AppKernel + routing.yml).

Minimal steps:

1. composer require funddy/jsrouting-bundle. Pin the constraint and check it against your Symfony version first — a 5-star, zero-dependent bundle from the Symfony2 era is almost certainly capped at symfony/symfony ~2.x. On Symfony 4+ this will not resolve without a fork.
2. Register the bundle in app/AppKernel.php:

   new Funddy\JsRoutingBundle\FunddyJsRoutingBundle(),
   

3. Import its routing so the "dump the routes as JS" endpoint is reachable, in app/config/routing.yml:

   funddy_js_routing:
       resource: "@FunddyJsRoutingBundle/Resources/config/routing.xml"
   

4. Add the generated script to your base layout, pointing at the bundle's dump route, and make sure it loads before your own JS that calls it.
5. Mark one route as exposed, then replace a single hardcoded URL in an existing AJAX call with a route-name lookup. That one replacement is your proof of value.

Where to look first: the bundle's controller that serves the JS payload, the Resources/config/routing.xml (to confirm the route name and URL pattern), and the generated output itself — open it in the browser and read it. That file answers 90% of the questions you will have about what the runtime API actually looks like, which matters here because the public surface is thin and under-documented.

Implementation Patterns

Expose routes explicitly, at the route definition. Whether via options: { expose: true } in routing.yml or the equivalent annotation default, exposure is opt-in. Resist the temptation to expose everything — see the performance note below.

Call by route name, not by URL string. The whole point:

// before
fetch('/admin/users/' + id + '/edit');
// after
fetch(Routing.generate('admin_user_edit', { id: id }));

Treat route names as the contract between back end and front end. When a route's path changes, the JS keeps working; that is the entire return on investment.

Prefer data attributes for the first paint. Anything already rendered server-side (form actions, links, pagination) should stay in Twig and be read out of data-* attributes. Use JS routing for the dynamic fragments — modals, async table rows, post-submit redirects — where no server-rendered element exists to hang a URL on.

Namespace route names in a small JS wrapper. Route names live as free-floating strings, so typos are silent until a user clicks. A thin module with an explicit ROUTES constant map — generated from a manifest or written by hand — turns runtime failures into a single place to audit and grep.

Version the generated payload. Serve the dump as a cacheable asset with a build hash or Symfony asset version in the URL, so a route change invalidates browsers. This is the single biggest operational win over regenerating per request.

Locale and parameters. If your app is localized, the locale is usually a route parameter; pass it explicitly rather than assuming the JS bundle silently inherits the server session's locale. Verify this in the dumped output before you rely on it.

Gotchas and Tips

• "Route not found" at runtime means it isn't exposed. The bundle only emits exposed routes. The error surfaces in the browser console, not at build or deploy time — there is no compile-time check that a route name you reference in JS exists.
• Missing required parameters fail late. Route requirements (\d+, slugs) are not validated client-side the way they are server-side. A numeric ID formatted as a string can produce a subtly wrong URL that 404s only in production.
• Cache invalidation bites twice. app/console cache:clear after route changes, and a browser cache bust on the generated JS. Forgetting the second is the classic "it works on my machine" report.
• Subdirectory and proxy deployments. If the app lives under /app behind a load balancer, confirm whether generated URLs are absolute or root-relative. Absolute URLs baked from the request host will break behind a proxy unless trusted proxies are configured.
• Dumping every route is expensive. The payload grows with your route table — parameters, requirements, and defaults all get serialized. Restrict exposure and dump at build time, not per request.
• Escaping. If you interpolate a generated URL into HTML via string concatenation, you inherit the usual XSS surface. Route parameters are user-influenced; encode at the insertion point.
• Maintenance risk is the headline. Five stars, zero dependents, Symfony2-only. There will be no security patches and no Symfony 5/6 port. If you are on a legacy Symfony2 app that already ships this, it is fine and low-blast-radius; if you are starting fresh, use FOSJsRoutingBundle (the maintained Symfony equivalent) or, on Laravel, Ziggy — same pattern, supported code.
• Debugging tip: when a route behaves unexpectedly, diff your routing.yml against the dumped JS rather than reading the bundle source. The dump is the ground truth of what the browser has.