Laravel Crud Laravel Package

Getting Started

This is a starter kit more than a package — you don't composer require it into an existing app, you clone it and build on top. Treat the first hour as "read the repo, not the docs" because docs are thin and the value is in the generated code.

Minimal path:

1. Clone and boot with Docker. Bring up the compose stack first (docker compose up -d), then exec into the app container for all artisan/composer/npm commands. Running artisan on the host against a Dockerized DB is the most common first-day stumble.
2. Read in this order:
   • docker-compose.yml / Dockerfile — understand what services exist (app, db, likely queue/scheduler) and which ports are exposed.
   • routes/web.php — see how CRUD routes and RBAC middleware are wired.
   • The CRUD generator command (usually app/Console/Commands or a service provider) — this is the actual product surface.
   • app/Http/Livewire (or app/Livewire) — the shipped components you'll copy/customize.
   • RBAC config — almost certainly spatie/laravel-permission under the hood; confirm before assuming.
3. Run migrations + seeders to get the roles/permissions and a login user, then log in through the Bootstrap auth views.
4. First use case: scaffold one throwaway resource (e.g. Post) end-to-end — generate, migrate, open the index, create/edit/delete one row. This shows you the full loop (component, view, form partials, validation, policy) before you commit to the architecture.

If you can't get the generator to produce a working resource in that first session, stop and evaluate whether the boilerplate is worth the archaeology — at 18 stars the community support won't rescue you.

Implementation Patterns

Generator-first, then own the code. The core workflow is: run the CRUD command, inspect the four or five files it emits (Livewire component, Blade views, form partial, migration), then edit them like hand-written code. Don't expect to "regenerate" later — treat output as a one-shot scaffold. This is the single most important mental model for day-to-day use.

Wire Select2 and Flatpickr inside Livewire's lifecycle, not on document.ready. Because Livewire morphs the DOM, plugin instances get destroyed on re-render. The reliable pattern:

// wire:ignore on the <select>, then re-init on Livewire navigation & component updates
document.addEventListener('livewire:navigated', initPlugins);
Livewire.hook('morph.updated', ({ el }) => initPlugins(el));

For Select2 backed by wire:model, keep wire:ignore on the select and push changes back explicitly via $wire.set('field', value) inside Select2's change handler. Flatpickr is more forgiving but still needs re-init if the input is inside a conditional block.

RBAC at three layers. Day-to-day you'll touch:

• Route middleware (role: / permission:) for coarse gating.
• Laravel policies for per-model authorization inside Livewire actions ($this->authorize(...)).
• UI hiding — gate buttons/columns with @can so the interface matches the policy.

Centralize the permission names in a seeder or enum; string-typo'd permissions that silently return false are a classic time sink.

Table/index pattern. Livewire list components with public $search, public $sortField, public $sortDirection, and WithPagination. Add debounced search (wire:model.live.debounce.300ms) — the boilerplate often ships wire:model only, which means a query-per-keystroke.

Docker env separation. Keep a .env.docker (or compose environment: block) distinct from host .env so DB host is the service name (db) rather than 127.0.0.1. Use the same image for local and prod; only override APP_ENV, volumes, and queue worker replicas.

Integrating into an existing app (rather than greenfield): cherry-pick — copy the Livewire component + form partial + the relevant JS init into your app, and reuse your existing auth and layout. Do not drag the whole repo in; the Bootstrap auth views will fight with Tailwind/Breeze.

Gotchas and Tips

• It's a template, not a dependency. No versioned upgrades, no release cadence, 18 stars. Fork it into your own repo on day one and pin everything in composer.lock / package.json. That is your upgrade path.
• Select2/Flatpickr + Livewire is the #1 source of bugs. Symptoms: dropdown renders as a plain <select> after a re-render, or the selected value resets. Fix is always wire:ignore + explicit $wire.set. Check the browser console for "Select2 already initialized" too — dispose before re-init.
• RBAC permission cache. After changing roles/permissions in code, run php artisan permission:cache-reset (or cache:forget spatie.permission.cache). Newly-seeded permissions that "don't work" are almost always this.
• Docker file permissions. Storage/bootstrap-cache writes often fail because the container user UID differs from the host. Either chown -R www-data:www-data storage bootstrap/cache inside the container or run as a mapped UID.
• Port collisions. The compose file likely hardcodes 80/3306/6379. If you've got a local MySQL or another project up, override with ${DB_PORT:-3307}:3306 rather than editing in place.
• Bootstrap vs Tailwind. If the auth views are Bootstrap, don't mix in Breeze scaffolding — you'll get two CSS pipelines and conflicting resets. Pick one and delete the other.
• Debugging Livewire: install the Livewire DevTools browser extension to inspect payloads; $this->dispatch('...') events not firing are usually because the listener component was conditionally rendered. Use Livewire::test(Component::class)->call('save')->assertHasErrors() for fast regression tests on generated components.
• Validation lives in the component, not FormRequests. Generated code typically inlines $this->validate([...]). For reusable rules, extract to a Rules array or a dedicated Form object; don't assume the boilerplate wired a FormRequest you can find in app/Http/Requests.
• Extension points that are stable: the Livewire components and Blade partials (yours to edit), the policies, and the seeders. Extension points that are fragile: the generator command itself — if you need customized output, edit it once, but expect it to drift from the shipped views over time.
• When to walk away: if you need first-class support, long-term maintenance guarantees, or a modern stack (Inertia/Vue, Tailwind-first), this is the wrong base. It shines for internal admin panels, MVPs, and learning Livewire + RBAC patterns — not for long-lived product code with an unfamiliar team.