Generator Laravel Package

Getting Started

Treat summerblue/generator as a dev-time accelerator, not a runtime dependency. Install it only where you scaffold:

composer require summerblue/generator --dev

Then publish its config and stubs so you can see what it will write before it writes it:

php artisan vendor:publish --provider="Summerblue\Generator\GeneratorServiceProvider"

Where to look first: the published config/generator.php (namespaces, paths, stub locations) and the stubs/ directory. Read the stubs before your first run — they define exactly what lands in your app, including the Bootstrap-era Blade markup and the route snippets appended to routes/web.php.

Prerequisite: this is a schema-first package. It introspects an existing table, so create and run your migration first. The database connection must be reachable and the table must exist before you invoke the generator.

First use case: a simple resource table (e.g. posts with title, body, published_at):

php artisan migrate
php artisan make:scaffold posts

You should end up with a model, a resource controller, form-request classes, Blade views (index/create/edit/show), and route entries. Immediately open the generated files, walk the routes with php artisan route:list, and commit the result as a baseline before hand-editing. From there, the typical path is "generate, then refactor" rather than "regenerate forever."

Implementation Patterns

Design the schema with scaffolding in mind. Column names, types, nullability, and foreign keys drive the generated validation rules and form fields. Explicit column comments or naming conventions (e.g. _id suffixes for relations) give you better output than letting the generator guess. Nail the migration first; scaffolding is a one-shot derivative of it.

One table at a time, in dependency order. Generate lookup/parent tables before child tables so foreign-key handling and relationship stubs land sensibly. For multi-table features, script it:

for t in categories tags posts comments; do php artisan make:scaffold "$t"; done

Wrap this in a shell script or a throwaway Artisan command so a fresh prototype environment can be rebuilt deterministically.

Customize stubs to encode your conventions once. Publish the stubs, then adjust:

• namespace and import ordering to match your project's PSR-12 style
• declare(strict_types=1); if you enforce it
• view layout (@extends('layouts.app') vs. component syntax)
• validation rule templates (e.g. 'required|string|max:255' instead of bare types)

This is the highest-leverage extension point: every subsequent generation inherits your edits, and you avoid a cleanup pass on each table.

Use it for admin panels, not public features. The generated controllers are plain resource controllers — perfect as a CRUD back office. Wrap the generated routes in your admin middleware group, or generate into an Admin namespace and move the routes manually:

Route::middleware(['auth', 'admin'])->prefix('admin')->group(function () {
    Route::resource('posts', Admin\PostController::class);
});

Generate, then prune. The generator produces a full surface area (all seven resource actions, all views). Delete unused actions (create/store for read-only reference tables), swap findOrFail for scoped bindings, and pull authorization into policies or authorizeResource in the controller constructor.

Pair with form requests as the validation seam. The generated request classes are the natural place to layer in Rule::unique(...), exists, enum validation, and prepareForValidation() normalization — rather than editing controller methods.

Gotchas and Tips

It is effectively unmaintained (last release 2022). Pin your Laravel version and verify compatibility before adopting. Schema introspection historically relies on doctrine/dbal, and DBAL 2→3 API changes plus newer Laravel schema-builder behavior can break generation on Laravel 9+. If introspection throws, check the DBAL version in composer.lock first — that's usually the failure point, not the package's own code.

Generation is destructive. Files are overwritten without meaningful prompts in most setups. Always commit (or stash) before regenerating, and diff the output: git diff after a scaffold run tells you exactly what the generator thinks your model should look like, which is a fast way to learn its conventions.

Route appending is the messiest part. The generator writes into routes/web.php, which can produce duplicate resource declarations on re-runs or clash with your existing route structure. After generating, inspect the route file, deduplicate, and consider moving generated routes into a dedicated routes/admin.php that you register yourself.

Config caching bites. If you publish config and edit it, run php artisan config:clear before regenerating — otherwise you'll edit stubs and paths and wonder why nothing changes.

Views are Bootstrap-flavored, not Tailwind. On Laravel 8+ projects the default frontend is Tailwind, so generated Blade will look broken out of the box. Budget time to either restyle the stubs once (best) or swap the markup per view (tedious). Editing the stubs early pays for itself across tables.

Validation rules are inferred, not authoritative. nullable, enum, json, and text columns often yield loose or wrong rules. Treat generated rules as a starting skeleton and tighten them manually — especially anything writing to the database.

Watch the primary key and timestamps assumptions. Tables without a conventional auto-increment id, with composite keys, or with non-standard timestamp columns will generate broken code. Verify the model's $table, $primaryKey, $keyType, $incrementing, and $timestamps immediately after generation.

Naming matters. The package expects plural snake_case table names mapping to singular StudlyCase models. Irregular plurals and prefixed tables (tbl_posts) need manual correction or a stub tweak — don't assume inflector magic.

Debugging checklist when a command fails: confirm the DB connection in use (php artisan tinker → DB::connection()->getDatabaseName()), confirm the table exists, run with -v/-vvv for the underlying exception, and clear config cache. Most "generator is broken" reports trace back to one of those three.

Keep it in require-dev. Nothing at runtime depends on it, so exclude it from production installs (composer install --no-dev) and delete it from the project once your scaffolding phase is done — the generated code stands on its own.