Simple Router Laravel Package

Product Decisions This Supports

• Build vs. adopt vs. extract for routing. The core decision this package informs is whether routing in our non-Laravel PHP services is hand-rolled, pulled from a framework, or delegated to a small third-party component. That is a real architecture decision with maintenance consequences.
• "How much framework" — not "which framework." Useful when the answer is "we want Laravel's routing ergonomics but not Laravel's runtime." It supports a strategy of decoupling business logic from a full framework so services can run on minimal runtimes (shared hosting, small containers, cheap edge workers).
• Legacy PHP modernization roadmap. Lets us add structured, testable routing to an existing procedural/plain-PHP app incrementally, instead of sequencing a full framework migration as a prerequisite for any improvement.
• Internal tools, admin panels, webhooks, and single-purpose JSON APIs. Low-ceremony scaffolding where time-to-first-endpoint matters more than ecosystem depth.
• Standardization across a mixed codebase. If we run Laravel in some services and plain PHP in others, adopting a Laravel-shaped router reduces context switching and onboarding cost for engineers who already know Laravel's route DSL (groups, prefixes, parameters, named routes, middleware hooks).
• Vendor-risk and sourcing posture for a component. Adopting it is really a decision to own the code: it forces an explicit answer on "do we fork, pin, and maintain this, or do we standardize on a PSR-15 router?"
• NOT a decision it should drive: choice of primary application framework, API gateway/ingress strategy, or anything requiring vendor SLAs.

When to Consider This Package

Consider it when:

• The project is plain PHP (or a homegrown micro-framework) and currently has ad-hoc $_SERVER['REQUEST_URI'] matching or switch statements — the upside is immediate.
• The team already knows Laravel routing; the learning curve is effectively zero and the mental model transfers.
• The routing surface is small — a handful to a few dozen routes. The value proposition is ergonomics, not scale.
• You are willing to pin an exact version, vendor or fork the source, and treat it as first-party code with your own tests around it.
• You want something small enough that one engineer can audit the entire router in an afternoon, with no transitive dependency tree to reason about.
• You are building a prototype or MVP and want to defer the framework decision without writing throwaway routing.
• You can absorb bus-factor-1 risk on a component whose failure mode is contained (bad routes, not data loss).

Look elsewhere when:

• You are already on Laravel, Symfony, Slim, or Laminas. The native router is battle-tested, maintained, and free — introducing a second router is churn with no payoff.
• You need PSR-7/PSR-15 interoperability and a broad middleware ecosystem. This constrains you to this package's conventions.
• You require enterprise support, an SLA, security advisories, or a documented CVE response process. With 11 stars and 0 dependents, there is no community backstop, no Stack Overflow corpus, and no independent security review.
• You are in a regulated or high-blast-radius environment (PCI, HIPAA, SOC 2 scope). A single-maintainer component in the request path is a hard sell at audit time.
• You need advanced routing: route caching/compilation, reverse routing at scale, host/domain constraints, OpenAPI generation, or deep DI-container integration.
• You are on a hot path where throughput matters. Without independent benchmarks against FastRoute or Symfony Routing, you'd be adopting an unvalidated performance claim.
• Your organization has many contributors to the codebase — the absence of an issue-triage community means your team becomes the maintainers by default.

Adoption gate (do before committing): confirm the license is compatible, check that tests and CI exist and pass, read the entire source, add contract tests around the routes you rely on, and write down the exit plan (likely a PSR-15 router) before the first production route ships.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source PHP router that brings Laravel's routing style to any PHP project, so we can build small services and modernize legacy PHP without standing up a full framework. The strategic value is optionality: lower runtime footprint, faster time-to-endpoint on internal tools, and less lock-in to a heavyweight framework for simple workloads. The cost is near zero to try. The risk is equally clear — it is a single-maintainer project with negligible adoption, no support contract, and no security track record. Recommendation: treat it as code we adopt and own, not a vendor we depend on. Run a bounded pilot on one internal tool or low-risk service, wrap it behind our own thin interface, and keep a documented swap path to a mainstream router. Do not put it in the request path of revenue-critical or regulated systems.

For engineering (the ask): The draw is the Laravel route DSL — groups, prefixes, parameters, named routes, middleware hooks — available in minutes in plain PHP, with a small codebase you can fully audit. The caveats are concrete: bus factor of one, no PSR-15 interop, no community issue triage, and unverified performance under load. What we need from you before adoption: (1) license check, (2) a one-day spike with a benchmark against FastRoute/Symfony Routing for our expected route counts, (3) a thin internal wrapper so routing calls aren't scattered through application code, and (4) contract tests that pin the behaviors we depend on. If the spike is clean, we take it; if not, we standardize on a PSR-15 router and lose a day.