- What does tanthammar/livewire-auto-routes do?
- It automatically registers Laravel routes for your Livewire components based on their file structure, so you do not have to write a Route::get call for every full-page component. The package is a thin, additive layer over Livewire routing and aims to keep URL mapping consistent across an app. Its value is convenience rather than new runtime capability.
- Does it support Livewire 3 and Laravel 10 or 11?
- Compatibility with Livewire 3 and Laravel 10 or 11 is unverified. The last release was May 2021, placing it in the Laravel 8 and Livewire 2 era, and Livewire 3 changed full-page routing semantics. Treat it as unproven on a modern stack until a spike and smoke test pass.
- How do I install and configure it in a Laravel app?
- Installation follows the standard Laravel Composer pattern, with package auto-discovery and a publishable config for the scan path. You should pin the package version and verify the Composer constraints against your target PHP and Laravel versions in a throwaway branch. Start with discovery scoped to a single module directory rather than enabling it app-wide.
- How are routes generated from Livewire component file structure?
- The package scans a configured directory or namespace and derives URIs from component class names and folder structure. The overview describes convention-based discovery rather than manual Route::get definitions. Verify the exact naming and nesting rules against your own component layout before relying on them.
- Will auto-generated routes work with php artisan route:cache?
- This must be explicitly verified because route caching can change when discovery runs relative to boot. If discovery touches the filesystem at boot, confirm that php artisan route:cache produces the same route set as local development. A mismatch between local and cached production routing is a deploy-day outage risk.
- What happens if an auto-generated route collides with a manual route?
- Silent conflicts are the dangerous failure mode because they can manifest as wrong-page renders rather than exceptions. The provided context does not document a precedence rule for discovered versus hand-written routes. Keep existing manual routes untouched during adoption and use a route:list diff to confirm the discovered set matches expectations exactly.
- Can I scope auto route discovery to a subdirectory or namespace?
- Yes, the intended adoption approach is to enable discovery scoped to a single new namespace or module directory. That keeps existing manual routes untouched and makes adoption incremental. Confirm the config option in the package README for your pinned version.
- How does it handle nested directories, dynamic segments, and parameter binding?
- The context does not confirm support for nested directories, dynamic segments, or parameter binding. It describes discovery based on file structure and class names, but the exact rules are not documented here. Test representative nested components and any parameterized routes in a spike before assuming they work.
- Is it safe to use in production if the package is unmaintained?
- The package has one maintainer, 17 stars, zero dependents, and no release in roughly three years, so there is no community backstop or security response process. It is MIT licensed with a small surface area, so forking or vendoring is viable if needed. Use it additively, pin the version, and add a smoke test that a known component resolves at its expected URI.
- What is the exit path if I stop using it?
- Delete the package, run the route list, and generate the equivalent explicit Route::get calls for the components that were discovered. That is a mechanical change, which makes lock-in risk acceptable even if the package is abandoned. Document the exit path before adoption so the implicit routing convention does not become invisible technical debt.