- What does imritesh/livecrud do for a Laravel application?
- It is a dev-time scaffolding package that generates basic CRUD operations for Laravel using Livewire components and Tailwind CSS views. It emits models, migrations, controllers, Livewire components, and Blade views into your application so you can skip writing that boilerplate by hand. It is not a runtime dependency, so once the files are generated the package steps out of the request path and you can remove it.
- How do I install imritesh/livecrud?
- It is designed to be pulled in as a require-dev Composer dependency and then driven through an Artisan generator command. Check the repository README for the exact command signature and any publishable stubs or config. Because the package targets the Laravel 8/9 and Livewire 2 era, validate it in a throwaway sandbox before adding it to a real project.
- Does imritesh/livecrud support Laravel 11 and Livewire 3?
- Compatibility is unproven. The last release is from 2021 and targets Laravel 8/9, Livewire 2.x, and Tailwind 2.x, while Livewire 3 changed lifecycle hooks, wire:model semantics, and removed several directives. Generated components and views will likely need stub rewrites before they compile or behave correctly on a current stack. Treat out-of-the-box support for modern Laravel as unconfirmed until you run a spike.
- Is imritesh/livecrud a runtime dependency or a dev tool?
- It is a dev-time scaffolder only. It writes CRUD artifacts into your codebase and then has no role at request time, which means no service container bindings, middleware, or route collisions to manage. Removal is trivial: delete the generated files and drop the require-dev entry.
- What license is imritesh/livecrud released under, and can I use it commercially?
- The repository reports NOASSERTION, which means there is no verifiable OSI license grant. For commercial work, that is a legal blocker until counsel resolves it, since you may not have clear rights to vendor or redistribute the package or its generated output. The safer path is reference-only: read the stubs, learn the patterns, and write your own generator.
- Does the generated CRUD include validation, authorization, and pagination?
- This is not documented and the generated code quality is unaudited. The package advertises forms, tables, validation, and common admin actions, but unknown is how it handles mass assignment, policies and authorization, and N+1 queries. Review every generated file before committing, because the moment it lands in your repository it becomes your code and its defects transfer to you permanently.
- Will re-running the generator overwrite files I have already edited?
- Idempotency is not documented, so assume the generator may overwrite hand-edited files on a re-run. Test regeneration in a clean branch or a scratch application before using it on a project with customizations. If you need repeatable regeneration, plan to fork the stubs and add your own safeguards.
- How does imritesh/livecrud compare to Filament, Nova, or Blueprint?
- It is a much smaller, older, single-maintainer project compared to Filament, Laravel Nova, or Blueprint, and it offers far less capability. Its only real value is velocity for internal admin surfaces on a Laravel 8/9, Livewire 2, Tailwind 2 stack. For modern applications, a maintained admin panel or a short internal make:crud command is usually the better trade.
- Is imritesh/livecrud still maintained?
- Effectively no. The last release is roughly four years old, the project has around 29 stars, zero dependents, a single maintainer, and no visible issue triage. Model upstream support as zero and assume the package is unpatched. If you adopt it, plan to fork and own the code rather than rely on future updates.
- How should I evaluate imritesh/livecrud before adopting it?
- Run a half-day spike in a sandbox that matches your production stack, generating CRUD for one representative entity and reviewing the output for validation, authorization, pagination, and query behavior. Weigh the result against the cost of a 200-line internal generator sized to your conventions. Given the license ambiguity and stale stubs, reference-only or fork-and-own under your own namespace are the recommended paths, not a long-lived require-dev dependency against Packagist.