Router Laravel Package

Product Decisions This Supports

• Routing architecture for the core product: keep Laravel's native router. Nothing in hoa/router justifies replacing the framework's HTTP router (Symfony Routing under the hood), which already gives you middleware ordering, route model binding, route caching, signed URLs, rate limiting, and versioned-prefix groups out of the box. This package is a reference point for a rejected alternative, not a candidate.
• Build vs. buy for a non-HTTP dispatch layer. The one genuinely interesting pattern here is grammar-described route matching (Hoa\Compiler grammars rather than regex/path segments). That is worth a look if the roadmap includes a rules-driven dispatcher — CLI command trees, telephony dial plans, IoT/device command routing, feature-flag or tenant-aware message dispatch — where the matching rules are owned by non-engineers and change frequently.
• Roadmap de-risking on "dynamic routing" requests. When a stakeholder asks for "routes defined in config by ops," this package is useful evidence for scoping: it demonstrates the concept but also demonstrates the cost (a grammar file, a compiler dependency, a bespoke runtime). Use it to argue for a constrained DSL or a config table over a general grammar engine.
• Dependency and vendor-risk policy. With 28 stars, zero dependents, an archived repository, and a last release of January 2017, this is a textbook entry for a "no unmaintained runtime dependencies in the request path" rule. Adopting it would set a precedent that costs more politically than it saves technically.
• Competitive/design scan for a spec. If we write an internal RFC on routing or dispatch, cite this as prior art for grammar-based matching, then benchmark against nikic/fast-route, league/route, aura/router, and Symfony Routing. That comparison is a half-day of work and improves the RFC.

When to Consider This Package

Consider it only when all of the following hold:

• The workload is outside Laravel's HTTP kernel — a long-running daemon, CLI tool, queue worker, or message dispatcher — so framework routing, middleware, and HTTP semantics are irrelevant.
• The matching problem is genuinely grammar-shaped (nested optional segments, typed captures, precedence between overlapping patterns) and cannot be expressed cleanly as path templates. If a {param} placeholder or a regex constraint works, it does not qualify.
• You are willing to fork and vendor it: pin the source into the repo, run it against your target PHP version (the 2017 release predates PHP 8; expect compatibility work), and accept ownership of security patches and bug fixes.
• The blast radius is small — a single internal tool, not a customer-facing surface, and easily replaced if it fails.
• A time-boxed spike has already proven it beats the native router on a concrete, measurable criterion (lines of routing config, ops self-service, cold-start time).

Look elsewhere when any of the following is true — which covers essentially every Laravel application today:

• The route is on the HTTP request path of a Laravel app. Use Laravel's router.
• You need PSR-7/PSR-15 interoperability or middleware ecosystems. Use league/route, nikic/fast-route + a dispatcher, or Slim.
• You need maintenance, CVE response, or a support contract. Nothing here has shipped in nine years; there is no one to escalate to.
• You are on PHP 8.x and do not want to own a compatibility fork. That is a hard stop for most teams.
• You need route caching, model binding, signed URLs, or subdomain/tenant scoping as first-class features. Rebuilding those around a foreign router is a multi-sprint tax with no product upside.
• Hiring and onboarding matter: no engineer joining the team will have seen this library, and the documentation is academic rather than task-oriented.

How to Pitch It (Stakeholders)

To executives — one line: Not a vendor decision and not a cost we should take on; recommend we decline and keep routing inside the framework we already pay for.

• Cost of saying yes: an unmaintained dependency (archived, last release January 2017, 28 stars, 0 dependents) in a part of the system where failures are user-visible. We would inherit security patching, PHP 8 compatibility, and on-call ownership.
• Cost of saying no: zero. Laravel's router covers the stated need, and the only capability gap is grammar-based matching, which no committed roadmap item requires.
• Opportunity cost: the integration and fork-maintenance work buys no customer-facing capability; the same effort applied to the existing router's gaps (rate limiting policy, tenant routing) delivers more.
• Recommendation: reject as a runtime dependency. Keep it as a reference artifact in the routing RFC, and revisit grammar-based dispatch only if a rules-owned-by-ops requirement is actually prioritized.

To engineering — the technical read:

• Archived upstream, no releases in nine years, no dependents to lean on for field reports, and a low automated quality signal. Treat "it still works on our PHP version" as unverified until a spike says otherwise.
• It solves a different problem than ours: grammar/compiler-driven matching rather than URL templates. That is a strength for embedded dispatch and a mismatch for HTTP request handling, where Laravel's router already provides middleware ordering, binding, caching, and signed URLs.
• Integration cost is the real blocker: adapting our controllers, middleware, and route-cache story to a foreign matcher would touch the request lifecycle — the highest-regression-risk code we have — for no user-visible gain.
• If a team wants to explore grammar-driven dispatch, scope it as a one-week spike in a non-production tool, vendored or not at all, with the native router as the fallback. Success criterion should be concrete (config lines reduced, ops can add a route without a deploy), agreed before the spike starts.
• Otherwise: use Route:: as-is; if a comparison is needed for the RFC, nikic/fast-route is the maintained benchmark, not this.