Generate Laravel Crud Laravel Package

Getting Started

Install and publish

composer require kajalpandya/generate_laravel_crud
php artisan vendor:publish --provider="Kajal\GenerateCrud\GenerateCrudServiceProvider"

If the provider isn't auto-discovered (older Laravel), add it to config/app.php. After publishing, check three things in this order:

1. config/generate_crud.php (or similarly named config) — route prefix, middleware, layout name, model namespace.
2. routes/ — the package registers its own routes; confirm the prefix and that they sit behind auth (or your admin guard) rather than web only.
3. resources/views/vendor/<package> — the published Blade views. This is where 90% of your day-to-day edits will happen.

First use case

Generate CRUD for a single table, e.g. posts, after the migration and model exist:

php artisan make:crud Post
# or check `php artisan list | grep -i crud` — the exact signature varies by version

Then hit /admin/post (adjust per your config) and verify you can list, create, edit, and delete. If the command name isn't what you expect, php artisan help output is the source of truth — this package has changed command names across releases.

Implementation Patterns

Database-first workflow. This is a schema-driven generator, so the reliable loop is: write migration → migrate → confirm the model/table is correct → run the generator. Generating against a table that doesn't exist yet is the most common way to get empty or broken output.

Regenerate into a scratch namespace first. Because generation writes into app/Http/Controllers, resources/views, and routes/web.php, run it once, inspect the diff, and only then wire it into your real app. Treat the generated code as a starting scaffold that you immediately take ownership of rather than something you re-run on top of customized files.

Wrap the generated routes in your own group. The package's routes are convenient for a prototype but rarely match production conventions. Move them under your admin route group with your own middleware:

Route::middleware(['auth', 'can:admin'])
    ->prefix('admin')
    ->group(base_path('routes/generated_crud.php'));

Customize via view overrides, not edits in vendor/. Publish the views once, then edit the copies under resources/views/vendor/. This is the only customization point that survives composer update.

Layer validation on the generated controller. Generated store/update methods typically have thin or placeholder validation. Replace with FormRequests and reuse them for both actions — this is the first thing to fix before shipping.

Use it as an internal admin tool, not public CRUD. Given the package's age and low activity, the realistic use is a fast internal back-office for a handful of tables, behind auth, on a Laravel version it actually supports. Don't build customer-facing surfaces on it.

Gotchas and Tips

Version compatibility is the main risk. With a small star count and low maintenance signal, verify the supported Laravel range in composer.json before committing. Test on a branch with your exact Laravel/PHP version — the package predates several framework changes (string helpers, RouteServiceProvider changes, PHP 8.x type strictness). Expect to patch generated controllers for modern type hints.

Regeneration overwrites. There's typically no "dry run" flag. Commit before generating so you can git diff and revert anything clobbered, especially routes/web.php, which generators often append to.

Route/model name collisions. Generated route names and controller namespaces can collide with your existing resources. Give the generator a prefix in config, or generate into a subnamespace.

Mass-assignment and fillable drift. Generated models/controllers assume $fillable matches the table. If you add a column later and don't re-run or manually update, the create/edit forms silently drop the field. Keep the migration and the generated form in sync by hand once customization starts.

Blade layout dependency. The published views usually @extends a specific admin layout name. If you swap to your own layout, grep the views for @extends and @section and update them centrally — otherwise every view needs an edit.

Asset publishing. Theme CSS/JS often needs --tag=public or a separate vendor:publish tag. Missing assets show up as completely unstyled pages; check public/vendor/ after install.

Debugging tip. If a page 500s immediately after install, the usual causes are (a) config not published, (b) route middleware referencing a guard you haven't defined, (c) missing APP_URL/asset path for the theme. Work through those three before reading the package source.

Extension point. The practical extension point is the published views plus your own controller layer — subclass or copy the generated controller into App\Http\Controllers\Admin and treat the package output as a template. Trying to hook into the generator's internals is not worth it for a package this small; forking or vendoring the two or three files you actually depend on is often the lower-cost path if you commit to using it.