symfony/routing keeps its vocabulary in the root and its machinery in folders

The install is one line, and the example is four objects

Installing the component is the standard Symfony composer line:

composer require symfony/routing

The readme's example then builds a route, puts it in a collection, gives the collection a request context and asks a matcher to match a path against it. The imports show the five classes involved:

use Symfony\Component\Routing\Generator\UrlGenerator;
use Symfony\Component\Routing\Matcher\UrlMatcher;
use Symfony\Component\Routing\RequestContext;
use Symfony\Component\Routing\Route;
use Symfony\Component\Routing\RouteCollection;

Four of those five are used in the visible half of the example. The fifth, the URL generator, is imported but its use comes after the part the readme shows, which tells you the example is walking through both directions rather than only the incoming one.

The controller is a route default, not a separate argument

The route is constructed with a path and a defaults array, and the only key in that array is the controller class:

$route = new Route('/blog/{slug}', ['_controller' => BlogController::class]);
$routes = new RouteCollection();
$routes->add('blog_show', $route);

$context = new RequestContext();

So a controller is expressed as a default value keyed with an underscore prefix, which is the convention that lets a route carry arbitrary parameters alongside the one that means something to the framework.

Two things are worth noticing in those five lines. The path uses a named placeholder in braces rather than a regular expression, so the requirement syntax is being handled by the component. And the controller is referenced as a class constant, so no string name has to be kept in sync by hand.

Routes are named, and the name is what generation needs

The route is added to the collection under a name rather than only being present in it. That name is the handle the other direction of the component uses, and it is why the URL generator is imported in the same example.

Matching turns a path plus a context into a set of parameters, and the readme's comment above the matcher says that routing can match routes with incoming requests. Generation is the inverse: given a name and a set of values for its placeholders, it produces a path.

The two namespaces reflect that split. The matcher lives under a Matcher namespace and the generator under a Generator one, each with its own implementation class.

The context object is shared between them, which is what makes the component host-aware: it is where the scheme, host and base path come from.

The root holds the vocabulary, folders hold the machinery

The root of the repository is where the shared types live. Route and RouteCollection are the data model. Router is the façade that ties them together, sitting next to RouterInterface, which is what an application should type against. RequestContext carries the per-request information, with RequestContextAwareInterface beside it for anything that needs the current context.

Then the compilation pair. RouteCompiler and RouteCompilerInterface are separated, which is the seam a project would implement to change how compiled routes are produced, and CompiledRoute is the output type.

Everything else is a subdirectory: Attribute, CacheWarmer, Command, Controller, DependencyInjection, Exception, Generator, Loader, Matcher, Requirement and Resources, plus Tests, a changelog and a phpunit configuration.

That distribution is the best documentation the readme offers, because it tells you which parts of the design are stable concepts and which are pluggable subsystems.

A bundle, a cache warmer and a DI extension are all present

Three entries in the root tell you how the component attaches to a framework rather than standing alone. RouterBundle is the bundle integration. The DependencyInjection directory holds the configuration wiring that a bundle registers. And the CacheWarmer directory is the visible sign that this component takes part in cache warming, meaning work can be done ahead of the first request rather than lazily during it.

The Command directory is there for command line integration, and the Controller directory for the framework-facing controllers the component provides rather than for the ones your application writes.

The Loader directory is the one to pay attention to if you are configuring routes from files, since loading configuration is a different problem from matching requests. The Requirement directory is the counterpart on the matching side, where the syntax inside path placeholders lives.

None of this is described in the readme, so the documentation link is where each of these is actually explained.

The default branch is 8.2 while the newest tag is 8.1.8

The branch naming here is not the usual main or master. The default branch is named for the minor version it targets, 8.2, while the newest release tag is 8.1.10. So the branch is already ahead of any published release.

That is a component-level mirror of how Symfony versions things: the major and minor of the component carry meaning, and the branch name tells you which one is in progress.

The release history shows three lines maintained in parallel. v8.1.10, v7.4.22 and v6.4.49 were all published on the same day, 28 October 2026, which is the signature of a project applying one change set to several supported branches at once.

The last push to that branch is dated 28 October 2026, so the 8.2 line is receiving work as the 8.1 line receives patches.

Issues and pull requests go to the monorepo

The resources section is the operational part of the readme, and it contains the detail that trips up first-time contributors. Documentation and contributing guides live on the main site, but issues and pull requests are to be filed in the main Symfony repository, with a link to that repository's issue tracker and pull request area.

So this repository is a subtree split of the monorepo. The split exists so that the component can be installed on its own with composer, while changes still flow through the central repository's review and release process.

The remaining lines are the funding ones. The readme says this package is looking for a backer and links the Symfony sponsorship and backers pages.

Editorial conclusion

symfony/routing fits a PHP application that needs named routes matched in one direction and generated in the other, and that is willing to work with the Symfony component model rather than a framework. It does not fit someone who needs YAML or attribute configuration without reading the documentation, because the readme covers none of that. Before adopting, read the routing documentation rather than the readme, and note that issues and pull requests are filed in the main Symfony repository rather than here.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. symfony/routing on GitHub