Yalr Laravel Package

Product Decisions This Supports

• Build vs. buy on routing conventions. If your roadmap includes standardizing how dozens of controllers declare their endpoints, this package is a cheap way to test the convention before you write an in-house router wrapper. It replaces bespoke Route:: blocks with colocated class-level declarations — a convention your team would otherwise hand-roll.
• Modular monolith / domain-package architecture. Class-based routing pairs naturally with "one domain = one package" structures, where each module owns its routes. That supports roadmap decisions about splitting the app into domains without adopting a heavier framework (Symfony, modular Laravel kits).
• Developer-experience and onboarding investment. Route definitions that live next to the controller reduce the "where is this endpoint defined?" search tax. This is a measurable onboarding lever for teams growing headcount, and a cheap experiment to justify a larger DX initiative.
• API surface scaffolding. For internal APIs or service boundaries, attribute/class-based route declarations make it easier to generate route inventories, OpenAPI stubs, or per-module middleware consistently — useful input to a "do we build a gateway/BFF?" decision.
• Deprecation and migration sequencing. Class-based definitions let you version or retire controllers as units instead of surgically editing a central route file, which lowers the cost of a phased API deprecation plan.
• Framework-upgrade planning. v1.6.0 adds Laravel 13 support. That tells you the package is intended to track current Laravel majors, so budget a small re-validation step for it in each future framework upgrade — the same line item you'd carry for any routing-layer dependency.

When to Consider This Package

Adopt it as a candidate when:

• You have many controllers and a large central route file that has become a merge-conflict hotspot and an onboarding problem.
• Your team is already PHP 8 attribute-friendly and comfortable reading framework internals — this is a convention layer, not a black box you can treat as infrastructure.
• You are modularizing and want routes to travel with their domain package.
• You are on, or planning to move to, Laravel 13+. v1.6.0 is a compatibility-only release (Laravel 13 support; no new features, no breaking changes), which is a positive maintenance signal — the maintainer is responding to upstream framework releases — but it is a single data point, not an LTS commitment.
• You can pin the version, vendor the code, or fork it if needed. With ~8 stars, 0 dependents, and a single maintainer (an agency), this is a bounded-risk dependency: acceptable behind a thin internal abstraction, not acceptable as load-bearing infrastructure in a regulated or multi-year product.
• You can validate it with a time-boxed spike against your real controller set, on your actual Laravel version, including route:cache, middleware ordering, and route-model binding.

Look elsewhere when:

• Your routing needs are conventional (resource routes, a handful of controllers) — Laravel's built-in routing plus invokable/grouped controllers already covers it, and adopting a niche package buys you nothing but a dependency.
• You need long-term support guarantees, security patching SLAs, or a large hiring pool familiar with the convention. Zero dependents means no ecosystem to lean on when the maintainer steps away.
• You rely on ecosystem tooling that introspects routes (Laravel route caching edge cases, third-party route/OpenAPI generators, Laravel Telescope-style inspectors). Verify compatibility explicitly — this is the most likely place a small routing extension breaks, and a Laravel 13 support bump specifically does not guarantee third-party route tooling keeps working alongside it.
• Your team's bottleneck isn't routing ergonomics. The value here is developer experience, not performance or capability; if DX isn't the constraint, the switching cost isn't earned.
• You can't accept a bus-factor-1 dependency. In that case, the right move is to borrow the idea — a small internal attribute-based route registrar is a few hundred lines and removes the external risk entirely.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed convention layer that lets Laravel applications declare routes directly on controller classes instead of maintaining one large central routes file. The strategic value is developer velocity and code organization: fewer merge conflicts, faster onboarding, and cleaner separation as we modularize the codebase. The package shipped a Laravel 13 compatibility update (v1.6.0), which is a modest signal that it is actively maintained. It remains a low-cost experiment, not a platform commitment — tiny community (8 stars, no downstream dependents) and a single maintainer mean we should trial it behind a thin internal wrapper, or replicate the pattern in-house, before any production dependency. Cost is negligible; the decision to make is whether route ergonomics is worth an engineering spike this quarter, and whether we're willing to carry a small compatibility check on every future Laravel major upgrade.

To engineering (summary): dentro/yalr provides class-based routing for Laravel — routes are declared on/alongside controllers rather than in routes/*.php. Upside: colocates endpoint definitions with behavior, supports domain-module packaging, and makes route inventories programmatically inspectable. The latest release, v1.6.0, is narrowly scoped: it bumps support for Laravel 13, with no new APIs, no behavioral changes, and no deprecations, so it should be a drop-in if we've pinned v1.5.x. Read it as a maintenance/health signal, not a feature. Risks are unchanged: minimal adoption, no dependents, single-maintainer, and unknown edges around route caching, middleware precedence, and third-party route introspection — re-verify those on Laravel 13 rather than assuming the version bump covers them. Recommendation: a one-to-two-day spike on a representative module at our target Laravel version, pin the version, and keep the public surface behind our own registrar/interface so we can swap it for ~200 lines of in-house code if maintenance stalls. Do not roll it out fleet-wide without that abstraction in place. Treat the "opportunity" score as a signal of an underused idea, not of production readiness.