Laracrud Laravel Package

Getting Started

1. Install into a scratch branch, never main.

composer require digitaldream/laracrud --dev
php artisan vendor:publish --provider="DigitalDream\Laracrud\LaracrudServiceProvider"

The package is archived and its last release is 2024-12-17. Before you invest time, resolve the version constraint against your Laravel version — expect Composer to complain on Laravel 11/12 and expect to pin doctrine/dbal explicitly. If it won't install, stop there; there is no upstream to fix it.

2. Prerequisites in your database. The generator introspects your schema (via Doctrine DBAL) and infers everything from it. That means the quality of the output is a direct function of your schema:

• A single-column primary key named id
• Real foreign-key constraints (not just user_id columns) — these are what produce belongsTo/hasMany methods and dropdowns in forms
• Conventional table naming (posts, post_comments) so model/relation names come out sensible
• MySQL is the best-trodden path; SQLite/Postgres introspection is where you should expect surprises

3. Run it against one table and read every generated file.

php artisan crud:generate posts

You should get, roughly:

• app/Models/Post.php — $fillable, $casts, relation methods
• app/Http/Controllers/PostController.php — full resource controller
• app/Http/Requests/StorePostRequest.php / UpdatePostRequest.php — rules derived from column types/nullability
• resources/views/posts/{index,create,edit,show}.blade.php
• A route entry for the resource

First use case: an existing, well-normalized database you've inherited and need an admin CRUD surface on top of. Do one table end-to-end — generate, migrate nothing, hit /posts, fix the layout, then decide whether to batch the rest.

Implementation Patterns

Generate in dependency order. Parents first. crud:generate users before crud:generate posts, otherwise the FK-driven relation code and form selects reference classes that don't exist yet and you spend the afternoon chasing missing imports.

Treat output as a one-way scaffold, not a codegen pipeline. The single most valuable habit: generate into a throwaway branch, git diff everything, then cherry-pick the files you want. Anything you hand-edit will be clobbered if you ever re-run the command on the same table.

Batch it in a loop for a legacy DB, then harden. A realistic sequence for a 20-table schema:

for t in users categories posts comments; do php artisan crud:generate $t; done

Then do a single sweep across the generated controllers and apply the fixes that are almost always needed:

// before
public function store(StorePostRequest $request)
{
    Post::create($request->all());
    return redirect()->route('posts.index');
}

// after
public function store(StorePostRequest $request)
{
    Post::create($request->validated());
    return redirect()->route('posts.index')->with('status', 'Post created');
}

That's the recurring pattern: the generator correctly produces a FormRequest, then the controller ignores it with $request->all(). Swap to validated() in every controller you keep.

Wire generated views into your app shell. The blades are standalone Bootstrap-flavored pages. Replace their surrounding markup with @extends('layouts.app') (or point the published config's view/layout settings at your existing layout) so you're not maintaining two design systems.

Layer the things the generator can't know. Generate first, then add on top: policies/authorize() calls, eager loading (Post::with('user')->paginate(15)) in index, scoped queries for tenancy, and soft-delete awareness in the unique rules.

Use the published config as the customization surface. Namespaces, view path, route prefix/file, and pagination all live there — change them there rather than editing files under vendor/. Same for published stubs: copy, edit, keep them in your repo so a composer update can't silently change your output.

Gotchas and Tips

• It overwrites. There is no --force guard worth trusting. Commit before every run, or generate in a branch. This is the #1 way people lose work with this package.
• Archived = no fixes. Pin digitaldream/laracrud to an exact version in composer.json, and don't put it in require — require-dev keeps it out of production installs, which is where it belongs since it only matters at codegen time.
• Validation rules are type-derived, not business-derived. varchar(255) becomes string|max:255, nullable columns get nullable, unique indexes get unique:posts,slug. All of it is a starting point. Specifically re-check: unique rules with soft deletes (add Rule::unique(...)->ignore($post)), enum columns, boolean checkbox handling, and any column with a DB default that shouldn't be required in the form.
• No FK constraint, no relation. If author_id exists without a constraint, you get no belongsTo and a plain number input instead of a select. Add the constraints in a migration first — it's faster than hand-writing the relations afterward.
• Non-standard schemas break inference. Composite primary keys, UUID PKs, non-id PKs, polymorphic columns, and pivot tables will produce wrong or missing code. Skip those tables and write them by hand.
• $fillable is generated from the columns, so watch for it being too permissive if your table has is_admin, role, or status columns. Trim it before shipping.
• After generating, clear caches and check routes. php artisan route:list | grep posts catches duplicate/missing route registrations immediately. php artisan optimize:clear avoids the classic "generated the controller but Laravel is serving the old one."
• Debugging generation failures: run with -v and read the DBAL error — it's usually a column type DBAL can't map (JSON on old versions, spatial types, enum) or a table with no PK. Adding an exception in the config/attribute list is easier than patching vendor code.
• Extension point when config isn't enough: the generator classes are ordinary classes — subclass one, override the method that builds the stub data, and bind your subclass in a service provider. Do that instead of editing vendor/, or the next composer install erases your work.
• Budget for the cleanup honestly. The realistic ratio on an unfamiliar schema is roughly 20% generating and 80% reviewing, hardening, and styling. If you only need two CRUD screens, write them by hand — the setup and version-wrangling cost isn't recovered until you're generating a dozen-plus tables against a schema that already follows every convention it wants.