Jsrouting Bundle Laravel Package

Technical Evaluation

Bottom line: hard no for a Laravel stack; high-risk legacy dependency for a Symfony stack. The package is a Symfony2-era bundle, not a Laravel package, and the metadata alone (0 stars, 0 dependents, last release 2017-02-15) disqualifies it from anything we'd have to support beyond the next Symfony upgrade.

Architecture fit

• The package is FOSJsRoutingBundle, which does one thing: expose selected Symfony routes to the browser via a fos_js_routing_js controller endpoint that emits a JS Routing object, consumed as Routing.generate('route_name', params).
• That mechanism depends on Symfony's Routing component, DI container, HttpKernel event system, and Twig. Laravel has none of those. Installing it into a Laravel app is not an integration problem — it's category error. Laravel's idiomatic equivalent is a route-manifest generator (Ziggy-style), not this bundle.
• Even within Symfony, the bundle targets Symfony 2.x and PHP 5.x assumptions (asset publishing to web/bundles/..., Twig 1.x, sensio/framework-extra-bundle). Symfony 4+ removed the bundle asset-publish convention; Symfony 6/7 will fail Composer resolution outright.

Integration feasibility

• Fit as-is: near zero. The only realistic path is a throwaway feasibility spike to confirm the install failure, not a production attempt.
• The capability (URL generation from the client without hard-coded paths) is worth having, but it is roughly 150–250 lines of code to reproduce: enumerate exposed routes at build time, emit a JSON manifest keyed by route name, resolve params in a small JS helper. That gives us the same API surface with no third-party runtime dependency and no public route-inventory endpoint.
• Provenance check needed: the package name (versh/jsrouting-bundle) does not match the repository it claims (FriendsOfSymfony/FOSJsRoutingBundle), and the star count belongs to neither upstream. That is a fork of unknown diff fidelity. Before any evaluation spend, diff the fork against upstream and confirm no injected code.

Technical risk

• Supply chain / abandonment (critical): nine years without a release, no security advisory channel, no maintainer. We would own the fork permanently, including every CVE in its dependency tree.
• Security surface (medium): the bundle publishes an endpoint that returns the route table. Exposure is opt-in via options: { expose: true }, and the API only generates URLs (it does not dispatch), so the design is reasonable — but a misconfigured whitelist leaks internal route names, parameter names, and path structure to any anonymous client.
• Framework drift (critical): even if it installs today, it will not survive the next major Symfony upgrade, and we get no warning because there is no issue tracker activity to watch.
• Observability gap (low): client-side Routing.generate calls fail at runtime when a route is renamed, with no server-side signal — silent breakage in the field rather than a failed build.

Key questions to close before a decision

1. Which framework is the actual target — Laravel or Symfony, and which major version? The request framing and the package metadata disagree.
2. Is the requirement real, i.e. does the frontend genuinely need server-authoritative URLs, or are we solving a problem that a typed API client or a build-time manifest already solves?
3. Can we serve a static, build-generated route manifest instead of a runtime endpoint? If yes, this package has no role regardless of framework.
4. If Symfony, is upstream FriendsOfSymfony/FOSJsRoutingBundle (or its modern successor) still viable, and does it support our Symfony/PHP versions?
5. Who owns this fork if we adopt it, and what is the replacement plan?

Integration Approach

Stack fit

• Laravel: reject the package; adopt or build a build-time route manifest. Reference implementation: Laravel's route:list --json output post-processed into a JS/TS module, or the established tighten/ziggy-style package. Same DX, no Symfony coupling, no runtime endpoint.
• Symfony 4+: reject the package; use upstream if a supported version exists, otherwise build the manifest generator.
• Symfony 2.8/3.x legacy app: this is the only environment where the bundle is conceivable, and only as a stopgap. Vendor the code, pin the commit, and schedule removal.

Migration path

1. Spike (0.5 day): attempt composer require versh/jsrouting-bundle in a scratch container of the target framework. Expected outcome is a dependency-resolution failure; document the exact blocker as the evidence for the decision record.
2. Capability audit (1 day): grep the frontend for hard-coded URLs and Routing.-style calls to size the real need. If nothing exists yet, the requirement is speculative and the answer is "define the contract, don't buy the package."
3. Build the manifest (3–5 days): an artisan/console command that walks the router, filters by an explicit allowlist, and emits routes.json + a ~100-line resolver. Committed or emitted as a build artifact; served as a static asset.
4. Resolve and verify (1–2 days): resolver handles required vs optional params, defaults, query-string extras, absolute vs relative, and localization prefixes.
5. Cut over behind a flag: ship the resolver alongside any interim hard-coded URLs, flip per-screen, then delete the old paths.

Compatibility

• Must confirm against the real matrix before estimating: framework major, PHP version, Twig version, asset pipeline (Webpack Encore/Vite), and whether the frontend is a full SPA, a server-rendered app with sprinkles of JS, or a hybrid like Inertia/Turbo. In the last case a manifest is usually unnecessary and we should say so.
• ES modules and TypeScript matter: an asset convention that expects a global Routing script tag published to a public directory does not fit a modern bundler without a shim.
• Localized routes and host/scheme-specific routes are the common edge cases that break naive manifest generators — validate them in step 4, not in production.

Sequencing Decision record → spike evidence → manifest implementation → contract test asserting every emitted route name resolves and every resolver key exists server-side → staged rollout. Do not sequence the manifest work before the audit confirms the requirement; the audit is the cheap gate.

Operational Impact

Maintenance

• Adoption means permanent ownership of an unmaintained fork. Every Symfony/PHP upgrade becomes a manual patch exercise with no upstream to rebase against. The build-time manifest alternative is owned code with a small, readable surface — cheaper over any horizon longer than one release cycle.
• If we vendor it anyway: pin to a commit SHA, vendor the source into the repo, add a licence and provenance note, and put a removal ticket in the backlog with an owner and a date on day one.

Support

• Zero dependents means zero ecosystem bug reports, zero Stack Overflow answers post-2017, and no one to ask when the asset-publishing step silently stops working. Expect internal-only support from the first day. Budget roughly 1–2 engineer-days per framework upgrade for diagnosis alone.
• Documentation is Symfony2-era and will actively mislead junior engineers on install and asset wiring. Any onboarding guide has to be written by us.

Scaling

• The runtime endpoint is a per-page-load HTTP request unless baked in at build time. At any real traffic this should be a cached static asset, which again argues for the build-time manifest — it removes the request, the origin hit, and the cache-invalidation problem in one move.
• Payload grows with the number of exposed routes, not the number used. Keep the allowlist tight; a 500-route app exposing everything produces a bloated script and a wider attack surface.
• Generation itself is cheap; the scaling cost is entirely in staleness and cache busting.

Failure modes

• Silent route drift: route renamed or removed server-side, deployed JS still calls the old name → runtime exception, often only on a rarely visited screen. Mitigation: contract test in CI that cross-checks emitted route names against the router.
• Stale route table behind a CDN: new deploy, cached manifest → users get 404s on links that exist. Mitigation: content-hashed manifest filename or versioned query param.
• Over-exposure: a route added without review gets published, leaking internal path structure or admin-only endpoints. Mitigation: default-deny allowlist, reviewed in PR, plus a test that fails if the exposed count changes unexpectedly.
• Parameter mismatch: optional params, defaults, and query-string extras resolve differently client vs server. Mitigation: golden-file tests against server-generated URLs for a representative route set.
• Upgrade breakage at the asset layer: publishing conventions removed in newer framework versions, resulting in a 404 for the router script and a totally non-functional frontend.

Ramp-up

• API surface is genuinely small — generate a URL, read the base URL — so day-one productivity is fine for a developer who gets it wired up. The cost is concentrated in setup (asset publishing, exposure config) and in the troubleshooting that has no upstream to consult.
• Estimate roughly 1 day for a developer who has never seen Symfony bundles, and the same for the manifest alternative. Since the ramp-up cost is a wash and the ownership cost is not, the build-time manifest wins on total cost of ownership at any meaningful scale.

Recommendation: reject the package. Close the framework question first — it changes the recommendation from "use Ziggy" (Laravel) to "use upstream or build the manifest" (Symfony) — but in neither case does this 2017 fork belong in the dependency tree.