Laminas Router Laravel Package

Product Decisions This Supports

• Build vs. buy for routing infrastructure. laminas/laminas-router is a decision input whenever a team is scoping HTTP route resolution rather than business logic: literal path matches, path-segment matches (optionally regex-validated at segment boundaries), full regex routes, and matching on scheme, HTTP method, and hostname. If a spec calls for host- or method-aware routing, or for composing route types into a tree for fast lookup, this package already covers it — that is a "buy" (adopt) vote against writing a bespoke dispatcher.
• Architecture choice: framework-coupled vs. framework-agnostic. The package is a routing engine, not a full HTTP kernel. That supports a product decision to keep routing out of the framework layer — relevant if you are building an internal shared library, a service template, or a multi-framework platform where route definitions must outlive any one framework. The 3.15.0 release moving laminas-http to require-dev is a meaningful signal here: the router is decoupling from the legacy Laminas HTTP stack, improving its fit for PSR-7-oriented consumers. A PM should still validate PSR-7 compatibility directly against the docs rather than the README blurb, which still describes the laminas-http request/response contract.
• Roadmap sequencing for migration work. Releases 3.18.0 and 3.19.0 pre-announce a v4.0: soft @final annotations on classes, Laminas\Router\Http\RouteMatch renamed to HttpRouteMatch, HttpRouteInterface introduced while Http\RouteInterface is deprecated, and deprecations documented for the 4.0 removal. This lets you size a v4 upgrade as a discrete roadmap item now, and it tells you to avoid new code against the deprecated interface and the old RouteMatch name so the upgrade stays cheap.
• Licensing and compliance sign-off. BSD-3-Clause is permissive and OSI-approved, with no copyleft obligations and no attribution burden beyond notice retention. That removes the legal review typically needed before adopting GPL/AGPL components in a distributed or SaaS product.
• Runtime/platform support matrix. Recent releases track PHP forward aggressively: 8.1 dropped in 3.16.0, 8.2 support added in 3.10.0, 8.3 in 3.12.0, 8.4 in 3.14.0, 8.5 in 3.16.0. Net: current releases require PHP 8.2+. This is a clean fit for a "modern PHP only" platform policy and a hard blocker if any part of the estate is still on 8.0/8.1.
• Use-case triage. Best-fit scenarios: Laminas MVC / Mezzio-adjacent services, internal admin or API tiers with non-trivial host/method routing, or a compatibility layer when consolidating several PHP services onto one router. Poor-fit scenarios: a Laravel application (Laravel's router is the native, tested path and this package adds nothing), or a team that wants batteries-included middleware, DI, and controller resolution in a single dependency.

When to Consider This Package

Adopt when all of the following hold:

• You are already inside, or deliberately standardizing on, the Laminas ecosystem (it is a natural fit as a router adapter in Mezzio or as the routing layer for laminas-mvc-family services).
• Your routing requirements genuinely exceed plain path matching — hostname-, scheme-, or method-based routing, regex-constrained segments, or tree-composed route sets where lookup performance matters.
• You want a small, single-responsibility library rather than a routing-plus-everything framework component, and your team accepts wiring the surrounding middleware/DI itself.
• Your PHP baseline is 8.2 or newer, and you can absorb a v4.0 major upgrade within a normal release cycle.
• You can live with a volunteer-maintained, Linux Foundation–governed project with no commercial SLA — this is the single biggest qualifier.

Look elsewhere when any of these apply:

• You are on Laravel. Use the framework router. Introducing this package means two routing layers, two sources of truth for URLs, and duplicated auth/middleware semantics for zero functional gain.
• You need vendor accountability. 35 stars and a single-contributor pattern across many releases (3.9.0 through 3.19.0 are largely one-PR, one-contributor releases) means a real bus-factor and responsiveness risk. If the router is on a critical path with uptime commitments, prefer a commercially supported or much higher-adoption alternative — nikic/fast-route, symfony/routing, or aura/router — or budget for in-house fork capability.
• You need proof of ecosystem adoption before internal approval. The supplied data shows zero dependents. Treat that as a verification task, not a verdict — a router is typically a transitive dependency of larger frameworks, so raw dependent counts understate real-world usage. Ask Engineering to confirm actual transitive use in your stack before citing adoption as evidence in a review.
• You need a batteries-included solution. This package will not resolve controllers, run middleware, or generate URLs for you out of the box; if the team's realistic capacity for glue code is low, a fuller framework or a higher-level routing package is the better call.
• You cannot tolerate a major-version bump soon. v4.0 deprecations are already published; a "no breaking upgrades for 24 months" policy conflicts with this dependency.

How to Pitch It (Stakeholders)

For executives: We evaluated a small open-source PHP routing library for the component of our services that decides which code handles which URL. It is permissively licensed (BSD-3, no copyleft exposure, no legal friction), actively maintained with releases through mid-2026, and already tracks PHP 8.2–8.5, which aligns with our runtime policy. It is a narrow, well-scoped dependency — not a framework — so it does not expand our platform footprint. The honest caveats: it is volunteer-maintained with no vendor support contract, and its public adoption signal is thin, so it is a fit only where we are already in or deliberately choosing the Laminas ecosystem. Recommendation: approve for evaluation in a non-critical service, not as a platform-wide standard, pending an engineering check of transitive usage and a PSR-7 compatibility confirmation.

For engineering: The library gives us literal, segment (regex-validated), and full-regex path matching plus routing on scheme, method, and hostname, composable into a priority-ordered tree for fast lookup — so we stop hand-rolling host/method dispatch. Two things to plan around: (1) releases 3.18–3.19 have already flagged the v4.0 breaking changes — soft @final on classes, Http\RouteMatch → HttpRouteMatch, and HttpRouteInterface replacing the deprecated Http\RouteInterface — so write new code against the new names to keep the upgrade mechanical; (2) laminas-http moved to require-dev in 3.15.0, meaning the router is decoupling from the legacy HTTP stack, but the README still describes the laminas-http request/response contract — verify the PSR-7 story against the docs before we commit. Our own work is the middleware/DI glue and URL generation it does not provide.

Decision ask: one two-week spike in a single non-critical service, with exit criteria of a working router configuration, a v4 upgrade cost estimate, and written confirmation of ecosystem adoption — then a go/no-go on wider use.