Router Laravel Package

Product Decisions This Supports

• Build vs. buy for route registration plumbing. This package is a candidate only for the "buy" side of a very small decision: whether to hand-roll a controller-scanning route registrar (~1–2 days of work plus tests) or adopt an MIT-licensed 1.x package. It does not inform platform-level architecture choices, and it should not be framed as one.
• Convention standardization for CRUD-heavy surfaces. The real product lever here is convention (attribute_or_get vs prefix) and http_methods_map: choosing one is effectively choosing a team-wide naming contract for controllers and URLs. That is a people/process decision (onboarding cost, code review norms, merge-conflict frequency in routes/web.php) more than a technology decision.
• Scope of "magic" in the codebase. Every route derived from a method signature is a route a reviewer cannot see in a diff. This package forces a product-level call on how much invisible behavior the team tolerates in the request path — the highest-blast-radius part of the app.
• Guardrails as a feature. strict (fail on duplicate verb+URI or duplicate route names), report_skipped_routes, LocalOnly, and DoNotDiscover are governance features, not conveniences. They let a PM argue for "fail the build on route collisions" as a quality bar, which is a legitimate, low-cost win independent of this specific package.
• Where the feature can safely live. Realistic use cases: internal admin/back-office, CMS scaffolding, prototypes, and demo apps where URL aesthetics and external API contracts don't matter. Not: public APIs, versioned endpoints, anything a third party integrates against, or anything an SEO/analytics surface depends on.
• Roadmap impact is a velocity bet on greenfield work only. Expect reduced boilerplate on new resource controllers; expect near-zero benefit and real migration cost on an existing app with hand-tuned routes, names, and middleware ordering.

When to Consider This Package

Adopt-worthy only if all of these hold:

• Greenfield or a bounded new module. Nothing that requires rewriting existing route files and re-verifying named-route usage across views, clients, and tests.
• You are on PHP 8.3+ and Laravel 13.x already. The README pins laravel components: ^13.0. On Laravel 10/11/12 you cannot install it, so this is a blocker, not a friction point.
• You accept the URL grammar or can override it everywhere. The default shape is /user/{id}/show — parameter segments are interleaved before the method name, and /{id} sits inside the resource path. If you need /users/{user} and clean REST semantics, you will be writing #[Route(uri: ...)] attributes on most methods, which erases the benefit.
• You have an owner who will fork it. Zero stars, zero dependents, and a README whose status badge points at a different repository (qoqn/laravel-router) than the distributed name (poshtive/router) is a strong signal this is a personal or renamed project. Treat it as vendored code you maintain, not a dependency you receive updates from.
• The team will tolerate a spike to answer operational questions the docs don't. Specifically: interaction with php artisan route:cache, whether discovery runs per-request or once at boot, how generated route names look and whether route()/to_route() in Blade and tests keep working, and latency of directory scanning on a large app/Http/Controllers tree.

Look elsewhere when any of these apply:

• Laravel < 13, or a near-term upgrade cadence you don't control.
• The routes are a customer-facing API contract, or you rely on route:list, IDE route navigation, Ziggy, or generated OpenAPI to reason about endpoints. Invisible routes degrade all of these.
• You need named-route stability across releases. Route naming is barely documented here; duplicate-name detection exists, but the naming scheme itself isn't specified.
• You want a maintained dependency with a security-response path. Nothing in the repo signals that.
• Your controllers are already thin and your routes/*.php is small. The problem this solves may not exist for you — verify the pain before buying the cure.
• You need child-controller nesting: that convention requires every method in the nested folder to take an Eloquent model parameter or registration fails. That's a brittle rule to inherit.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed developer-efficiency package that auto-generates Laravel routes from controller method names and PHP attributes. Its appeal is narrow and honest: less boilerplate and fewer merge conflicts when many engineers add endpoints to the same route file, plus built-in duplicate-route detection. It is not a platform bet. Signals are weak — zero stars, zero dependents, a single narrow version compatibility window (PHP 8.3 + Laravel 13), and no observable support commitment. Recommendation: fund a one-week, timeboxed spike inside an internal admin surface at most. Do not standardize on it, and do not let it touch any externally consumed API. Treat any adoption as "we own a fork," with the maintenance cost that implies. If the spike doesn't show a measurable reduction in route-file churn, stop — the default Laravel explicit-routes pattern is not the problem worth solving this quarter.

To engineering: The honest DX case is convention-based discovery via #[Route], #[Where], #[LocalOnly], #[DoNotDiscover], and #[IgnoreParentMiddleware], with two naming conventions and a http_methods_map shortcut for REST verbs. strict gives you fail-fast on duplicate verb+URI and duplicate names, which is genuinely useful. The costs are equally concrete: routes become invisible in code review; the default URL shape interleaves parameters before the action (/user/{id}/show), so keepOrder and explicit uri: overrides become routine; discovery must be validated against route:cache; and the child-controller convention hard-fails without an Eloquent parameter. Please answer those four questions in the spike write-up before we discuss adoption, and assume we are the maintainers.