Laravel Livewire Ui Laravel Package

Getting Started

Install and publish

composer require bastinald/laravel-livewire-ui
php artisan vendor:publish --provider="Bastinald\LivewireUi\LivewireUiServiceProvider"
php artisan migrate

The package is opinionated: it assumes Bootstrap 4/5 (not Tailwind) and Livewire 2.x. Confirm both are present before expecting the UI to render — install laravel/ui for Bootstrap scaffolding if you need it.

Where to look first

1. php artisan list livewire — discover the scaffolding commands actually exposed by your installed version. The command surface has shifted across releases, so trust artisan list over the README.
2. config/livewire-ui.php — after publishing, this is the single source of truth for layout paths, redirect targets, and route gates.
3. resources/views/vendor/livewire-ui/ — every Blade view/component ships here. This is your customization surface.
4. routes/web.php — confirm the auth routes and any generated CRUD routes were registered.

First use case: stand up auth in five minutes

php artisan livewire:auth

You get Login, Register, ForgotPassword, ResetPassword, VerifyEmail, and UpdatePassword Livewire components wired to /login, /register, etc. Point config('livewire-ui.layout') at your app shell and you have a working auth flow without writing a single validation rule.

The second use case, CRUD scaffolding, is where the kit earns its keep on internal tools. Run the CRUD command against a model and you get index/create/edit/delete components, form requests, and pagination in one shot.

Implementation Patterns

Model-first CRUD is the intended workflow. Create the model and migration first, then let the kit generate the Livewire surface:

php artisan make:model Post -m
# edit migration, run it
php artisan livewire:crud Post

Regenerate after adding fields — the generator reads $fillable and column types to build the form and data table. Doing it the other way round (scaffold then add fields by hand) works but doubles the effort.

Compose the shipped Blade components rather than rebuilding them.

<x-livewire-ui::input name="email" label="Email" type="email" />
<x-livewire-ui::select name="role" :options="$roles" />
<x-livewire-ui::modal wire:model="showModal">...</x-livewire-ui::modal>

These wrap Bootstrap markup, emit the right BEM classes, and surface wire:model errors. Rolling your own form controls throws away the only real reason to use the package.

Use the trait-based auth on Livewire components. The generated auth components rely on Illuminate\Foundation\Auth\Access\AuthorizesRequests plus the package's own redirect mixin. If you extend an existing profile page, use LivewireUi\Auth\Concerns\RedirectsAfterAuth; (or equivalent in your version) so $redirectTo behaviour stays consistent.

Integration with existing apps: if you already have Auth::routes() or Breeze, disable the package's auth routes in the config ('routes' => ['auth' => false]) and pull in only the components you need. The package is designed to be all-or-nothing but the config flags make it selectively adoptable.

Layout override pattern. Rather than editing published files (which you then have to diff on every upgrade), copy them once and set:

// config/livewire-ui.php
'layout' => 'layouts.app',

Then customize layouts.app — upgrades to the package won't clobber your changes.

Gotchas and Tips

Bootstrap is a hard requirement, not a preference. Dropping these components into a Tailwind app (Breeze, Jetstream, default Laravel 9+) produces invisible modals, unstyled tables, and broken pagination. Either commit to Bootstrap or budget a rewrite of every component.

Livewire 3 will bite you. The package predates Livewire 3's removal of wire:model.defer, the @entangle changes, and the new $listeners → #[On] attribute syntax. If you're on Livewire 3, expect to patch generated components — the wire:model bindings in particular.

Regenerating CRUD silently overwrites. Back up hand-edited generated components before rerunning the CRUD command after a schema change. There is no --force guard in most versions; it just writes.

Migration ordering with an existing users table. The auth scaffold ships its own users migration. If you already have one, delete the published migration file before php artisan migrate, or you'll get duplicate-table errors. Check database/migrations/ for a newly added timestamped file first.

Route name collisions. The auth routes register names like login, register, password.request. If Breeze/Jetstream is also installed, whichever loads last wins — usually the wrong one. Comment out the competing routes or gate the package's auth in config.

Debugging a component that renders blank. Nine times out of ten it's the layout: Livewire's root element must be a single <div>, and the package's default layout omits @livewireStyles/@livewireScripts if you override it. Confirm your layout includes both plus Bootstrap CSS.

Extension points worth knowing:

• config('livewire-ui.layout') — swap the shell without touching vendor code.
• Publish tags: --tag=livewire-ui-views vs --tag=livewire-ui-config — publish selectively so future upgrades stay clean.
• The generated components are plain classes — extend or use their traits rather than fork them when you need shared behaviour across many CRUD screens.

Maintenance reality check. With ~100 stars and dated dependencies, treat this as a scaffolding starter, not a framework. Generate once, immediately vendor the output into your own app/Http/Livewire/ and resources/views/livewire/ directories, and stop depending on the package for anything beyond the initial composer require. That way upgrades to Laravel or Livewire are your problem to solve, not blocked on a maintainer who may have moved on.