Weave Code
Routing Laravel Package
nette/routing
Nette Routing is a standalone two-way router for PHP that maps SEO-friendly URLs to presenter/action pairs and back. It supports route masks, parameters, localization, and is used by the Nette Framework.
Nette Routing: two-ways URL conversion
Frequently asked questions about Routing
- What is nette/routing and can it be used inside a Laravel application?
- Nette Routing is a standalone, framework-agnostic two-way URL converter that maps SEO-friendly URLs to presenter/action pairs and back through matching and URL construction. It can technically be used inside a Laravel application, but only behind an adapter and only for bounded scenarios. It is not a Laravel router replacement, because Laravel routing is tied to the HTTP kernel, middleware, controller resolution, route model binding, and helpers like route().
- Is nette/routing a drop-in replacement for Laravel's router?
- No. nette/routing operates at a different architectural layer and would bypass Laravel middleware, authorization, CSRF/session handling, route model binding, signed URLs, route caching, and the route() helper unless you wrap all of that yourself. Treat it as a bridge or standalone URL service, not as a primary Laravel dispatcher. Replacing Laravel routing with it is a high-risk architectural change with low expected payoff.
- How do I install nette/routing in a Laravel project?
- Install it with Composer using require nette/routing, which also brings in its nette/http and nette/utils dependencies. Keep the integration in a dedicated module rather than app/Providers/RouteServiceProvider.php, and leave Laravel's router as the default dispatcher. Hide Nette types behind an interface such as LegacyRouteMatcher or CanonicalUrlBuilder so application code does not depend on the package directly.
- Does nette/routing support Laravel 10, 11, and 12?
- nette/routing is a PHP package, not a Laravel package, so Laravel compatibility depends on your PHP version rather than a Laravel-specific integration. The 3.1 line requires PHP 8.1 or newer and the project has moved toward PHP 8.2-oriented support, so Laravel 10, 11, and 12 on PHP 8.2+ are the realistic target. There is no official Laravel integration package, so you own the adapter and compatibility testing.
- How does nette/routing mask syntax compare with Laravel route parameters?
- Nette uses route masks with its own placeholder syntax such as <id>, plus its own constraint, default, and flag conventions, while Laravel uses {id} placeholders with where() constraints and middleware attached to routes. The syntax and behavior are different enough that you must choose either Nette or Laravel as the single source of truth for route definitions. Maintaining both representations creates two URL truths and predictable drift between inbound matching and outbound generation.
- Will Laravel middleware, auth, and route model binding work with nette/routing matches?
- Not automatically. A Nette match returns parameters, but Laravel middleware, authorization, CSRF/session assumptions, and route model binding do not apply unless you carefully re-enter Laravel's dispatch path with the matched parameters. Matching before Laravel middleware can bypass auth and CSRF assumptions if the sequencing is wrong, which is both a security and correctness boundary. Plan explicit re-dispatch and parity tests for any affected endpoint.
- What license does nette/routing use?
- The license metadata is reported as NOASSERTION, so legal should confirm the actual license and any redistribution obligations before adoption. Do not assume a permissive license based on the Nette ecosystem alone. Record the confirmed license in your architecture decision record and review it before shipping the integration.
- How should I test a nette/routing integration in Laravel?
- Build a route-parity test suite that compares Nette matching and constructUrl() output against Laravel's route() output for the same route set. Cover parameter conversion, regex constraints, defaults, localization, signed URLs, and edge cases such as trailing slashes and encoded characters. Assign clear ownership of the adapter and parity suite, and define a rollback plan in case Nette matching diverges from Laravel behavior in production.
- What are the production risks of using nette/routing alongside Laravel routing?
- Key risks include dual routing creating two URL truths and drift, regex constraints and route ordering becoming fragile at scale, and matching outside Laravel potentially bypassing middleware or authorization assumptions. The package also has low external dependents in the available data, meaning limited community proof and fewer Laravel-specific examples. A healthy release cadence with static analysis cleanup and PHP 8.5 support does not by itself make it a good Laravel routing fit.
- When is nette/routing a good fit for a Laravel project, and what are the alternatives?
- It is reasonable only for clearly bounded work such as a Nette-to-Laravel migration bridge, a standalone URL-generation or matching service outside the Laravel kernel, or a compatibility layer for legacy Nette route definitions. Approve a time-boxed proof of concept with route-parity tests and a written exit strategy, not a core-routing replacement. For most Laravel applications the better alternatives are native Laravel routing, packages like Ziggy for JavaScript URL generation, or standalone routers such as Symfony Routing or FastRoute when you genuinely need routing outside the framework.
Weaver
How can I help you explore Laravel packages today?