Route Exporter Bundle Laravel Package

Getting Started

This is a Symfony 2.x bundle (sed/route-exporter-bundle), so it only makes sense in a legacy Symfony 2 application — it will not install or run on Symfony 3+ without forking. Treat "getting started" as onboarding into a legacy maintenance workflow.

1. Install

   composer require sed/route-exporter-bundle
   

   Pin the version that matches your Symfony minor (the bundle predates modern PHP constraints; expect to add "php": "~5.6|~7.0" overrides in composer.json if Composer complains about the platform requirement).

2. Register the bundle in app/AppKernel.php:

   public function registerBundles()
   {
       $bundles = [
           // ...
           new Sed\RouteExporterBundle\SedRouteExporterBundle(),
       ];
       return $bundles;
   }
   

3. Look here first: run php app/console list sed (or list | grep -i route) to discover the actual command name — bundles of this vintage register commands under a sed: namespace. Read the bundle's Command/ directory next; that's where the format flags and output options live.

4. First use case: dump your entire routing table to a single file for auditing or migration:

   php app/console sed:route:export --format=yml > config/routes.dump.yml
   

   The most common reason to reach for this package is not runtime routing but producing a portable snapshot of your routes — for documentation, a routing diff, or migrating from annotation/PHP routing to YAML.

Implementation Patterns

Documentation / inventory generation. The primary pattern: run the exporter in a build step and commit the result, or publish it to your docs. Because it can emit YAML, XML, and PHP, you can keep one canonical dump and let downstream tooling consume whichever format it prefers.

# CI step — fail the build if routes changed unexpectedly
php app/console sed:route:export --format=xml > build/routes.xml
git diff --exit-code build/routes.xml

Config migration workflow. The highest-value use for this bundle: you have a legacy app with annotation-based or routing.yml-scattered routes and want one normalized file. Export to YAML, then prune/merge into your canonical app/config/routing.yml. Because the exporter reflects the compiled router, you get resolved paths, defaults, and requirements in one place — much easier to reason about than tracing included routing files.

# Dump, then selectively move entries into your main routing config
php app/console sed:route:export --format=yml > /tmp/all-routes.yml

Format-driven tooling. Pick the format by consumer, not preference: YAML for human review/diffs, XML for tooling that expects Symfony's XML routing schema, PHP for programmatic regeneration or inclusion in code-gen pipelines.

Programmatic integration (if the bundle exposes a service). Check the bundle's Resources/config/services.yml for an exporter service ID. If present, inject it into your own command or controller to export filtered subsets (by name prefix or bundle) at runtime — useful for generating per-module route manifests in a multi-bundle app.

Snapshot + diff as a safety net. In a large legacy app where a single routing.yml edit can shadow routes elsewhere, exporting before/after a refactor and diffing is a cheap regression check on route definitions.

Pre-deploy audit. Run the export against the target environment (--env=prod) so the dump reflects the environment-specific route loading (dev-only debug routes, etc.) — a quick way to confirm nothing unexpected is registered in production.

Gotchas and Tips

• Symfony 2 only. This will not work on Symfony 3+ — the AppKernel, app/console, and routing config conventions are all pre-3.0. If you're not on 2.8 (or at least 2.3), this bundle is a dead end; write your own router:debug --format serializer instead.
• Unmaintained and obscure. 10 stars, 0 dependents means no ecosystem, no StackOverflow answers, and no upstream fixes. Vendor it or fork it if you depend on it. Budget time to read the source rather than docs.
• Format fidelity is the main risk. Exported routes lose information that the compiled RouteCollection doesn't retain — e.g., original controller notation (AcmeBundle:Default:index vs. resolved FQCN::method), host requirements, condition expressions, and some option flags. Always diff the export against what your router actually resolves with router:debug before trusting it as a migration source.
• YAML escaping. Export-to-YAML can produce values with regex requirements that round-trip badly if your YAML dumper is old (backslashes, quotes in requirements). Validate any exported file with php app/console router:debug after loading it back.
• XML namespaces. If consuming the XML output, ensure you keep the Symfony routing namespace (http://symfony.com/schema/routing) — hand-edited XML dumps frequently lose it and then fail to import.
• Clear the cache after installing/enabling the bundle. Registering a bundle in AppKernel isn't picked up until you clear app/cache — a stale cache will make list not show the command and can look like an install failure.
• Extension points are thin. Because this is a small export utility, don't expect event hooks or a pluggable formatter. If you need a custom format, the pragmatic path is a small wrapper command that calls the router service (@router / router in the container) and serializes $router->getRouteCollection() yourself — ~40 lines of PHP and you own the output fidelity.
• Environment matters. router:debug and any exporter reflect the environment you execute under; run with --env=prod when the goal is an accurate production route map.