Laravel Code Generator Laravel Package

Getting Started

crestapps/laravel-code-generator is a scaffolding engine that turns database tables (or hand-written JSON resource files) into models, controllers, form requests, routes, views, migrations, and translations. Unlike make:* commands, it reads schema metadata to infer fields, types, and validation rules.

Install and publish config:

composer require crestapps/laravel-code-generator
php artisan vendor:publish --provider="CrestApps\CodeGenerator\CodeGeneratorServiceProvider"

Where to look first:

1. config/codegenerator.php — path conventions (models_path, controllers_path, views_path), default template flavor, date/soft-delete defaults, and which generators run by default.
2. resources/views/vendor/code-generator/ (after publishing views) — the actual stubs. Reading one template explains more about output shape than the docs do.
3. laravel-code-generator/resource_files/ — the JSON "resource files" that describe a model. Every command is ultimately driven by one of these.

First use case: scaffold from an existing table.

php artisan resource-file:from-database posts
php artisan create:resources Post --force
# or all in one:
php artisan create:scaffold Post

Then check app/Models/Post.php, app/Http/Controllers/PostController.php, routes/web.php, and database/migrations/ for the generated artifacts. create:scaffold chains model → migration → form request → controller → routes → views, so it is the fastest way to see the whole surface area before you customize templates.

Implementation Patterns

Resource-file-first workflow. Treat the JSON resource file in laravel-code-generator/resource_files/ as the source of truth, hand-edit it, then regenerate. You get deterministic, re-runnable scaffolding:

php artisan resource-file:create Post --fields="title:string, body:text, published_at:date"
php artisan create:resources Post --force

This is far more maintainable than scaffolding once and hand-editing generated controllers, which will be clobbered the next time someone regenerates.

Split the generators. In real projects you rarely want all six artifacts at once. Run the pieces independently so you only overwrite what you actually changed upstream:

php artisan create:migration Post --force
php artisan create:model Post --force
php artisan create:form-request Post   # hand-tuned, so no --force
php artisan create:controller Post --force
php artisan create:routes Post
php artisan create:views Post --force

Keep form requests hand-owned by simply never regenerating them after the first pass — that is the natural seam between generated and human code.

Programmatic generation in seeders or install commands. The facade lets you build scaffolding as part of a package install or a demo-data seeder:

use CrestApps\CodeGenerator\Facades\CodeGenerator;

CodeGenerator::createModel('Post', 'Post', $resourceFilePath);
CodeGenerator::createController('Post', 'PostController', $resourceFilePath);

Useful for tenant bootstrapping or for internal admin-panel tools where the CRUD set is derived from a customer-defined table.

Relations in the resource file. Define foreign_relations / relations in the JSON and the generator emits the belongsTo / hasMany methods plus the dropdown population in the generated form. Doing this via the resource file keeps the relationship wiring regenerable; adding relations by hand to a generated model defeats the point.

Custom templates over custom output. Publish the views and edit the stubs (--template-aware directories under the published path) rather than post-processing generated files. One template edit propagates to every future model; a post-processing script does not. A common pattern is a house-style template set checked into the repo under resources/views/vendor/code-generator/ so the whole team scaffolds identically.

Laravel 11 integration. v3.0.2 fixes the missing Kernel class error that broke generation on Laravel 11 (the framework removed App\Console\Kernel and App\Http\Kernel from the skeleton). If you are on Laravel 11, pin ^3.0.2. On 3.0.0/3.0.1 the route-registration and command-discovery paths throw when they try to resolve the old Kernel class.

Gotchas and Tips

The Laravel 11 Kernel fix is the only functional change in 3.0.2. Everything else in this release is Dependabot bumps to webpack-dev-middleware and follow-redirects inside /docs — documentation site dependencies that are not shipped in the Composer package. Zero runtime impact for anyone not on Laravel 11, and no breaking changes, no deprecations, no new commands or config keys. Treat 3.0.2 as a safe drop-in for 3.0.1.

Generation overwrites without much ceremony. --force silently replaces files; without it you get an interactive prompt that is easy to answer wrong in CI. Never run create:resources --force in a pipeline against a directory containing hand-edited controllers. Scoping each generator command separately (see above) is the practical defense.

Resource files go stale. resource-file:from-database is a one-time snapshot, not a live binding. Add a column later and your resource file will not know until you re-run it — which then overwrites your hand-tuned field labels and validation. Diff the regenerated resource file before committing.

Validation rules come from the resource file, not the schema. Column type inference gets you string and required, but anything beyond that (email, unique, max:255, exists:) must be authored in the resource file's validation key. Generated form requests are a starting point, not a review substitute — this is the most common source of "the scaffolder produced insecure validation" complaints.

Route collisions. create:routes appends to routes/web.php. Regenerating a model whose routes already exist produces duplicate route names and Laravel throws on the second Route::resource. Either use --routes-prefix to namespace them, or delete the previous block before regenerating.

Config paths must be writable and match PSR-4. models_path and controllers_path in config/codegenerator.php are relative to app/. If you use a non-standard namespace (e.g. App\Domain\Blog\Models), update both the path and the namespace key, or generated namespace declarations will not autoload.

Template flavor matters for your frontend. The default templates emit Bootstrap markup and a matching layout. Tailwind/Livewire/Inertia projects need a published, edited template set — otherwise you generate views that reference form-group classes and a layouts.app that does not exist in your app.

Localization. Labels come from lang files the generator publishes per locale. If lang/vendor/code-generator/en/fields.php is missing, generated views fall back to humanized column names, which looks like a bug but is just an unpublished asset group.

Debugging output. When a generator produces nothing or a cryptic error, check the resource file JSON parses first (php artisan resource-file:create --help and the JSON schema comment at the top of a generated file are the fastest references). Malformed JSON typically surfaces as a silent skip rather than a parse exception.

Extension point. All generation funnels through CrestApps\CodeGenerator\Generators\* classes registered in the service provider's $generators array. Binding a subclass there is the supported way to add behavior (e.g. auto-adding a policy) without forking the package — but it is undocumented territory; read the provider source before relying on it across upgrades.