- What is dentro/yalr and how does it work with Laravel routing?
- Dentro/yalr, also called YALR (Yet Another Laravel Router), is a lightweight convention layer that lets you express routes as PHP classes instead of entries in routes/web.php or routes/api.php. It does not replace Laravel's dispatcher, so middleware, route-model binding, form requests, and policies remain framework-native. Think of it as an application-layer pattern similar to invokable controllers or attribute-based route registration, not an infrastructure commitment. It is best suited to teams that already prefer one class per endpoint.
- How do I install dentro/yalr in a Laravel application?
- The typical installation is composer require dentro/yalr, followed by registering the package service provider and publishing a configuration file that points at a route discovery directory. The package is hosted at github.com/digital-entropy/yalr, so check the README for exact provider registration and config publishing commands for your Laravel version. Installation is usually a matter of hours and is reversible. Do not migrate existing routes; add the package behind a config flag and test in a branch first.
- Which Laravel and PHP versions does dentro/yalr support?
- The available evaluation does not list exact composer.json constraints, so the first step is to open the package's composer.json and confirm it supports your current Laravel major and PHP version. Routing internals shift across Laravel majors, and a small package with a near-zero dependency graph has no strong forcing function to keep up. Pin exact Laravel and PHP versions before adopting. If the package does not publish a CI matrix covering Laravel 10, 11, and 12, treat version support as unverified.
- Does dentro/yalr work with php artisan route:cache and route:list?
- This is a blocking compatibility question and should be measured rather than assumed. Confirm that route:cache succeeds and that the cached output matches the uncached output, and verify that both route sets appear correctly in route:list with no collisions or ordering surprises. Directory scanning at application boot can become a silent performance regression if it does not participate in route caching. Run the checks in a branch before shipping anything.
- Can I use dentro/yalr alongside routes/web.php and routes/api.php?
- The safe approach is to coexist rather than migrate: leave routes/web.php and routes/api.php untouched and express only one new, self-contained surface such as a new API module or internal admin area as route classes. Verify in a branch that both route sets register correctly and that there are no collisions. Whether the package coexists cleanly or takes over route registration is one of the first questions to answer before writing code. Keep the change behind a config flag so reverting is a one-line change.
- How are middleware, route groups, and prefixes defined in dentro/yalr route classes?
- Middleware, middleware groups, withoutMiddleware, groups, prefixes, domains, and route names should be expressed per class, per method, via attributes, or in configuration, but the exact mechanism depends on the package's implementation. Check the README and source to confirm how each is declared, and test that named routes and route('x') URL generation still resolve. Because routing sits on the critical path of every request, any behaviour you cannot verify should be treated as a risk.
- Does route-model binding and named route URL generation still work with dentro/yalr?
- Because dentro/yalr is positioned as a thin adapter over Laravel's router rather than a replacement dispatcher, route-model binding, soft deletes, custom resolution, named routes, and route('x') URL generation should remain framework-native. The key is to verify that they are preserved rather than bypassed. Test implicit binding, custom keys, and soft-deleted models explicitly. If any of these are bypassed, the package becomes a framework fork in practice and the adoption cost rises sharply.
- Is dentro/yalr production-ready and actively maintained?
- The public adoption signal is very low: roughly 8 stars, 0 dependents, and no downstream bug reports, which means the package has not been hardened by other people's production traffic. It is single-maintainer open source, and routing sits on the critical path of every request, so a maintenance stall is a real operational risk. Treat any high static-analysis score as a signal to investigate, not to adopt. Pin versions, read the test suite, and keep an exit path before using it in production.
- How does dentro/yalr compare to spatie/laravel-route-attributes or invokable controllers?
- All three are application-layer conventions for keeping route definitions close to endpoint code. Spatie's route attributes have wider adoption and a larger dependency graph, while invokable controllers are pure Laravel with no extra package. Dentro/yalr fits teams that already think in one-class-per-endpoint style and are comfortable with attribute-driven or discovery-based configuration. It fits poorly on teams standardized on resource controllers and Route::resource, because you will end up with two idioms in one codebase.
- How do I test routes defined with dentro/yalr, and what is the exit path if the package is abandoned?
- Read the package's test suite first; a small package you can review in an afternoon is easier to trust than one you cannot. Integration-test your route classes with Laravel's HTTP tests to confirm middleware, binding, and URL generation behave identically to standard routes. The exit path depends on whether route definitions are declarative enough to mechanically convert back to Route:: calls. If they are, reverting is straightforward; if not, isolate the package to one bounded context so removal stays contained.