Livecrud Laravel Package

Getting Started

1. Install the package into an existing Laravel app (this generator assumes you already have a working Laravel project, not a fresh skeleton):

   composer require imritesh/livecrud
   

2. Confirm the frontend prerequisites. The package targets Livewire 2.x and Tailwind CSS. You need livewire/livewire installed, @livewireStyles in <head>, and @livewireScripts before </body> in your layout.
3. Publish the package assets/stubs so you can inspect and later customize what gets generated:

   php artisan vendor:publish --provider="Imritesh\LiveCrud\LiveCrudServiceProvider"
   

   Look in config/livecrud.php (or similarly named config) and the published stubs/ directory first — that tells you exactly what files the generator will emit and which placeholders it expects.
4. Create the model and migration first. Like most scaffolders, the generator reads the table schema to decide field types and validation rules, so php artisan make:model Post -m and php artisan migrate need to happen before generation.
5. Run the generator against the model (check the README for the exact signature — it is typically namespaced, e.g. php artisan livecrud:generate Post).
6. Expose it via a route and visit the page:

   Route::get('/posts', \App\Http\Livewire\PostCrud::class);
   

   If the page renders a Tailwind table with create/edit modals and delete buttons, you're set.

First use case: pick a single, flat resource with no relationships — a Category or Post table with string, text, boolean, and date columns. That is the shape this package is optimized for. Treat it as a sprint-0 CRUD screen for an internal admin tool, not as a foundation for a public-facing app.

Implementation Patterns

• Scaffold-then-own. The generated Livewire component and Blade view are normal application files. The intended workflow is: generate once, then hand-edit. Don't expect to re-run the generator against the same model without overwriting your changes — either commit before regenerating or delete and re-scaffold deliberately.
• Route-to-component mapping. Because the generator emits a full-page Livewire component, the simplest integration is a single Route::get pointing at the class. If you need it inside an admin panel, wrap it with Route::middleware(['auth']) or mount it as a child component inside your existing layout:

  @livewire('post-crud')
  

• Override stubs rather than post-editing. If you find yourself making the same edits to every generated component (adding $search, tightening validation, changing the pagination count), edit the published stub instead. That's the package's main extension point.
• Table-driven validation. The generator derives $rules from column definitions. After generating, move rules into a rules() method backed by a Form Request or a dedicated rules array so you can reuse them for API endpoints and tests.
• Search and pagination live in the component. Typical generated components expose public $search and use WithPagination. Call $this->resetPage() inside updatingSearch() if it isn't already there, otherwise pagination breaks when filtering.
• Modal-based create/edit. Most generated views use a single modal with a $isOpen/$editingId flag. When adding fields, remember to reset them in both the create() and edit() methods — the generated code often only clears a subset.
• Compose with your admin layout. Drop @livewireStyles/@livewireScripts into your existing layout once, and keep the generated view as a partial. Mixing the package's default layout with your own is the fastest way to get duplicate Tailwind resets.
• Use it as a schema-discovery exercise. Generate against several models, diff the output, and you'll quickly learn the package's column→input-type mapping (string→text, text→textarea, boolean→checkbox, date→date picker). That mapping is what you'll need to work around for enums, JSON columns, and foreign keys.

Gotchas and Tips

• Livewire version lock. This package's last release was August 2021, i.e. the Livewire 2 / Laravel 8 era. On a Livewire 3 or Laravel 10/11 app you will likely hit composer conflicts or runtime errors around $emit, wire:model, and lifecycle hooks. Check composer.json constraints before installing; if needed, pin Livewire 2 in a separate app or vendor the stubs into your own generator.
• Tailwind purging. Generated views live in resources/views/livewire, so they're covered by a standard content config — but if Tailwind classes disappear in production it's almost always because the package's published views are outside your content globs. Add the path explicitly.
• Missing scripts = dead interactivity. No @livewireScripts, no delete confirmation, no modals. It looks like broken JS but it's a missing directive.
• Primary key assumptions. Expect id as the key and $model->find($id) semantics. UUIDs, composite keys, and soft deletes generally aren't handled — you'll need to edit the generated edit()/delete() methods.
• Mass assignment. Generated components often call Model::create($this->all()) or update($this->all()). Verify $fillable/$guarded on the model before shipping; a permissive $guarded = [] plus a generated form is an easy mass-assignment hole.
• No file uploads, relationships, or authorization. The generator won't produce WithFileUploads, belongsTo dropdowns, or $this->authorize() calls. Add these by hand — don't assume the scaffold implies them.
• Validation is schema-derived, not business-derived. nullable, max:255, and required get inferred; unique constraints, enums, and cross-field rules do not. Treat generated rules as a starting draft.
• Debugging tip. Because this is a Livewire component, dd() inside render() still works, but Livewire::dump()/the Livewire devtools browser extension will show you the round-trip payloads faster when a modal silently fails to open.
• Extension points, in order of leverage: published stubs → published config (namespace/paths) → the generated component itself. If you need to change behavior beyond that, you're better off copying the generator into your app than upgrading around it.
• Licensing. The package's license is reported as NOASSERTION, meaning GitHub couldn't detect a recognized license file. If you're using this commercially, read LICENSE in the repo or contact the author — absence of a license is not permission.
• Maintenance risk. 29 stars, zero dependents, one release. Don't make it a runtime dependency of a long-lived product; vendor and adapt the generated code so an unmaintained package can't block your framework upgrades.