Laravel Livewire Discover Laravel Package

Getting Started

Install with Composer and let Laravel discover the service provider:

composer require joserick/laravel-livewire-discover

Start with the package README and the published config file, if available. Look first for the discovery paths and namespace/prefix settings; those are the main integration surface. A practical first use case is registering one non-default Livewire component directory, such as a module or domain folder, then rendering and testing a single component before expanding discovery to other modules.

v1.3.2 is a bugfix release and should be a safe upgrade. It is especially relevant if you mix default Livewire components with prefixed/discovered components.

Implementation Patterns

Use the package as a discovery layer for components that do not live in Livewire’s default location. Common patterns:

• Modular applications: register each module’s Livewire directory with a stable namespace/prefix, while leaving default app/Livewire discovery intact.
• Package components: register package-provided Livewire components from the package service provider so consumers can reference them through a predictable prefix.
• Incremental rollout: add one discovery root at a time, run component render/tests, then add the next root. This keeps alias collisions and namespace issues easy to isolate.
• Config-driven registration: keep paths and prefixes in config rather than hard-coding them in providers. This makes local/staging/package differences easier to manage.
• CI smoke tests: include tests that resolve and render at least one default component and one prefixed component. This directly exercises the namespace-ordering behavior fixed in v1.3.2.

Keep custom discovery in a dedicated service provider or config block, and avoid registering the same component through both default Livewire discovery and this package.

Gotchas and Tips

• Upgrade to v1.3.2 if using mixed namespaces. The release fixes a namespace restoration typo that could prevent default components from resolving after prefixed components were registered. Re-test default component resolution after any prefixed component registration.
• Ordering matters. Add a regression test that resolves a prefixed component first, then a default component. That is the failure mode addressed by v1.3.2.
• Watch for duplicate aliases. If a component is discoverable by both default Livewire discovery and a custom root, you may get conflicting or surprising resolution. Exclude overlapping paths.
• Clear caches after config changes. Run php artisan optimize:clear after changing discovery paths/prefixes, especially in environments using config or component caching.
• Debug with minimal cases. If a component does not resolve, compare a default component and a prefixed component in the same request/test. Check provider boot order and the registered namespace/prefix mapping.
• Keep prefixes stable. Component aliases used in Blade, routes, or tests should not change casually; treat discovery prefixes as part of your public component API.