Laravel Preset Laravel Package

Getting Started

The v1.1.0 release adds Livewire-powered authentication components with live validation. If you already use the package for auth scaffolding, this is the first release where you can drop in reactive login, registration, password reset, and related forms without writing custom Livewire components.

Minimal setup:

1. Install or upgrade the package:

   composer require <vendor>/<package>:^1.1
   

2. Ensure Livewire is installed and configured (v3 recommended):

   composer require livewire/livewire
   

3. Publish the package config, views, and migrations if you have not already:

   php artisan vendor:publish --tag=<package>-config
   php artisan vendor:publish --tag=<package>-views
   php artisan migrate
   

4. Confirm the Livewire auth components are registered. Most packages use auto-discovery; if not, check config/<package>.php for a components or livewire section.
5. Point your auth routes or Blade views at the new components. The most common first use case is replacing a static login form:

   <livewire:auth.login />
   

Start by reading the package’s README, the published config/<package>.php, and the Livewire component classes under src/Http/Livewire or src/Livewire. The login component is usually the best reference for how validation, guards, and redirects are wired.

Implementation Patterns

Drop-in auth views. Use the provided components directly in your existing layouts:

<livewire:auth.login />
<livewire:auth.register />
<livewire:auth.forgot-password />
<livewire:auth.reset-password :token="$request->route('token')" />

This is the lowest-effort path when you want the package’s default auth flow with live validation enabled.

Override validation without forking. Publish the views and Livewire components, then extend the base component or override its rules() method. Keep custom rules in a dedicated class so both the component and your tests share them:

protected function rules(): array
{
    return [
        'email' => ['required', 'email', Rule::unique('users')],
        'password' => ['required', 'confirmed', Password::defaults()],
    ];
}

Use live validation deliberately. Bind inputs with wire:model.live.debounce.500ms for email uniqueness checks and password strength feedback. Avoid .live on every field in large forms; use .blur for fields that trigger expensive queries. The package’s components should already debounce, but confirm before adding your own listeners.

Integrate with existing guards and redirects. Check the config for guard, redirect_after_login, and redirect_after_register. If your app uses multiple guards, set the guard per component or override the redirect() method. This keeps the Livewire components compatible with admin/customer auth separation.

Compose with rate limiting and middleware. Put the Livewire component routes behind the same throttling and guest/auth middleware as your existing auth routes. Live validation does not replace server-side throttling; keep throttle:login or equivalent in place.

Testing pattern. Use Livewire’s test helpers to assert both validation and auth behavior:

Livewire::test(Login::class)
    ->set('email', 'not-an-email')
    ->assertHasErrors(['email' => 'email']);

This is especially useful for regression-testing custom rules after publishing views.

Blade customization. Publish views when you need markup changes, but prefer overriding component methods for behavior changes. Mixing both without tracking upstream changes makes future upgrades harder.

Gotchas and Tips

• Livewire version mismatch. The new components likely target Livewire 3. If you are still on Livewire 2, check the package constraints before upgrading. Symptom: component methods not firing, or wire:model.live behaving like wire:model.
• Publish tags vary. Run php artisan vendor:publish without a tag first to see available tags. Publishing only config and forgetting views can leave you with stale markup after upgrading.
• Config caching. After changing the package config, run php artisan config:clear. Live validation behavior and component registration can appear broken when an old cached config is active.
• Email uniqueness queries during typing. Live validation on email fields can hit the database on every keystroke. Use debounce and consider a dedicated check-email endpoint or a lighter validation rule if the users table is large.
• Password hashing. Do not hash passwords in the component if the package already handles it. Double-hashing is a common failure when overriding store() or register().
• Session and CSRF. Livewire requests still need the web middleware group. If you mount components on custom routes, verify session and CSRF middleware are present or live validation will fail intermittently.
• Redirects after auth. Overriding redirect() in a subclass is supported, but make sure you return a URL or route name consistently. Returning null can leave users on the component after successful login.
• Localization. Validation messages come from Laravel’s validation language files. Publish or override them if your app uses non-default locales; the package’s views may also contain hard-coded labels.
• Extension points to prefer. Override rules(), messages(), redirect(), and authenticate()-style methods before editing published views. Use package events or hooks if documented; they survive upgrades better than view edits.
• Debugging live validation. If validation does not appear live, check the browser console for Livewire errors, confirm @livewireStyles and @livewireScripts are present, and verify the component is not nested inside another Livewire component without proper keys.
• Upgrade path. Since this is a minor release, treat it as additive, but re-publish views only if you have not customized them. Diff published views against the new package views to see what changed.