league/route: PSR-7 routing and PSR-15 dispatch on top of FastRoute

A router that hands work to PSR-15 handlers

league/route is the routing and dispatch component of The PHP League, and it is deliberately narrow. You give it a request, it matches a route, and it calls a handler.

The mechanism is standard PHP practice. The package is built on top of FastRoute, so the pattern matching work is delegated rather than reinvented, and the credits list names Nikita Popov for FastRoute alongside the package author, Phil Bennett. The added value is in the surrounding standards compliance and in the dispatch pipeline.

That pipeline is what makes the package useful to a team. A router on its own produces a match; a router that also runs middleware, resolves dependencies from a container and returns a PSR-7 response saves you from writing that glue. The README's own description calls it a fast PSR-7 based routing and dispatch component including PSR-15 middleware, built on top of FastRoute.

The audience is developers building their own HTTP stack. If you want a framework you configure, this is below that level. If you have already chosen your PSR-7 implementation, your PSR-11 container and your own middleware, this fills the routing gap without asking you to give those up.

The standards list is the real feature list

The README opens with a compliance statement, and it is worth reading closely because the list tells you what the package is allowed to assume about the rest of your application.

The package is compliant with PSR-4, PSR-7, PSR-11, PSR-15, PSR-16 and PSR-17. Those are the autoloader standard, the HTTP message standard, the container standard, the request handler standard, the simple cache standard and the HTTP factory standard respectively.

Mapped onto a request lifecycle, that means: messages are PSR-7 objects rather than something the router defines itself, the handler that answers a request is a PSR-15 handler, the router can look up services through a PSR-11 container, and PSR-17 factories can build the message objects. PSR-16 cache compliance means the package can participate in a caching layer without needing its own cache abstraction.

The practical consequence is that nothing here is proprietary. If your team has already standardised on PSR-7 messages, you pass them in. If you have a container, the router asks it. The README adds a polite line about compliance oversights, inviting a patch by pull request, which tells you the maintainers treat the list as a contract rather than a marketing claim.

The trade-off of standard compliance is that you supply the implementations. A PSR-7 implementation, a PSR-11 container and, if you want caching, a PSR-16 pool are separate dependencies you have to choose and wire up yourself.

Installing on PHP 8.3 and above, with Composer

The install path is a single Composer command, given in the README under the Install heading:

``` bash $ composer require league/route ```

The package name on Packagist is league/route, which is what the Composer command uses. The README also carries a badge for total downloads from Packagist, so the package is distributed the standard way rather than through a bespoke installer or a bundled binary.

The version requirements are the part to read before you start. The Requirements section lists the PHP versions supported by this version: PHP 8.3, PHP 8.4 and PHP 8.5. There is no mention of 8.0 through 8.2, so if your production fleet still runs an older PHP you have a problem, and the fix is a version choice rather than a configuration change.

The default branch of the repository is 7.x, and the README links the documentation for that branch tree, so the docs you read match the code you install as long as you are on the 7.x line.

The documentation itself is a site of its own at route.thephpleague.com, powered by Jekyll, and the README points contributors at the docs/ directory in the repository for changes to it. That separation between the package and its prose documentation is worth knowing before you go looking for usage examples inside the source.

Tests, static analysis and style rules live in the same tree

The README documents a single test command:

``` bash $ composer test ```

Underneath that, the repository layout shows a conventional PHP package. There is a src/ directory for the code, a tests/ directory for the suite, and phpunit.xml for the PHPUnit configuration, which is what the test command drives.

Static analysis is set up separately, with a phpstan.neon file at the root, so level and paths for PHPStan are configured outside the source. Code style is handled by .php-cs-fixer.php, the PHP CS Fixer configuration, and .editorconfig covers whitespace and editor conventions that several tools read. A .vscode/ directory and .github/ are also present, and the README carries a badge for the GitHub Actions test workflow status, so the suite runs in continuous integration as well as locally.

This is a small, tidy package, and the tooling tells you the maintainers run the usual quality gates: unit tests, static analysis, and an enforced style. There is also a CHANGELOG.md at the root, and a CONTRIBUTING.md that the README points to for the details of how to contribute.

For a library rather than an application, that is the whole review surface. There is no configuration file to understand and no service to run before you can use it.

Version 7.0.0 landed after a long gap in the 6.x line

The release history explains the version story. Three versions appear in the listing: 6.1.0 dated 2024-11-20, 6.2.0 dated 2024-11-25, and 7.0.0 dated 2026-07-14.

Read that pattern and two things stand out. The 6.x line saw two releases five days apart in November 2024, then nothing visible until the major bump in July 2026. A major version number in a mature package usually signals a breaking change, and the PHP version list tightening to 8.3, 8.4 and 8.5 is consistent with a release that drops support for older runtimes.

The last push to the repository was on 2026-07-14, the same day as the 7.0.0 tag, so the branch and the release are in step and there is no unreleased work sitting behind the tag. That is a clean state to adopt from.

The licensing is the MIT License, with a LICENSE.md file at the root and a badge in the README. That is about as permissive as it gets, so there is no copyleft obligation to think about if you depend on it in a proprietary application, and the documentation site is a separate concern from the code licence.

The upgrade cost for a team on 6.x is therefore a version jump with a runtime requirement attached, not an API migration you can postpone.

Where a routing component is the wrong choice

The honest limit of this package is that it does one job. Routing and dispatch is the job, and the README does not claim to be an application framework. There is no template engine, no controller base class, no dependency on a particular ORM or a queue, and no CLI tooling.

That is a strength for teams who have opinions about those layers and a weakness for teams who wanted them included. If your project needs a full stack for a small site, wiring up routing, PSR-7 messages, a container and PSR-15 middleware by hand is work a framework would have saved.

The other constraint is compatibility rather than capability. Because the package expects PSR-7, PSR-11, PSR-15, PSR-16 and PSR-17 implementations to exist, an application that has not chosen them has to choose them before it can use this. And a project that still runs PHP 8.2 cannot use the 7.x line at all.

There is also a documentation split to keep in mind. The usage documentation lives at route.thephpleague.com rather than in the README, so a reader working offline from the repository alone will find the README gives you the install command and the standards list, and not much more.

Editorial conclusion

league/route suits PHP developers who want routing that speaks the FIG standards without adopting a full framework, particularly teams already running PSR-7 messages, a PSR-11 container and PSR-15 middleware. It does not suit a project that wants a complete application framework with templating, routing and controllers in one dependency, and it does not suit teams pinned to PHP versions below 8.3, since the 7.x line lists PHP 8.3, 8.4 and 8.5 as the supported versions. Check three things before you adopt it: that your PHP version is in that list, that the PSR implementations you already use are compatible with the container and factory contracts it expects, and that the middleware stack you need is expressible as PSR-15 handlers. The 7.0.0 release is dated 2026-07-14 and the last push to the repository was on the same day, while the previous 6.2.0 dates from 2024-11-25.

Frequently asked questions

Official sources

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