Laravel Entity Generator Laravel Package

Getting Started

Install the generator as a dev dependency so it never ships to production:

composer require --dev ronasit/laravel-entity-generator

Laravel auto-discovers the service provider. First places to look:

1. php artisan list | grep make: — confirm the generator commands and their exact names.
2. php artisan make:entity --help — this is where the real options live (--only-entity, method selection, field definitions). Read the full help output before your first run.
3. Publish the config and stubs (php artisan vendor:publish --tag=entity-generator-config and the stubs tag) so you can see what will be written to disk before you run it against a real project.

A good first use case is a throwaway sandbox: generate a Post entity in a scratch branch, inspect every file the command touches, then decide which parts (model, migration, controller, requests, resource) you actually want the team to keep. Do not run the generator against a dirty working tree the first time — commit or stash so git diff shows exactly what was scaffolded.

Implementation Patterns

Scaffold-then-prune. The default generator run produces the full CRUD stack. The common day-to-day pattern is to generate the whole thing once, then delete or keep pieces per entity. When an entity is domain-only (a lookup table, a pivot, a value object), use --only-entity to get just the entity model/migration and skip the default CRUD methods entirely.

Pick the generation method deliberately. The generator supports multiple field/method strategies (the release notes reference "method C"). Treat the method flag as part of your team's documented convention — decide once, put it in your onboarding notes, and pass it consistently, because mixing methods across entities produces inconsistent controllers and requests.

Custom stubs are the integration point. Publish the stubs into your app and edit them to match house style: namespaces, repository bindings, DTO usage, test scaffolding. This is how you make generated code pass your linters and static analysis without manual cleanup on every run. Keep the published stubs under version control and review them on package upgrades.

Regenerate in isolation, review as a diff. Because the tool writes multiple files, the reliable workflow is: create a branch, run the generator (or re-run with --only-entity to add a model to an existing feature), then review git diff file by file. Generated migrations in particular must be read before php artisan migrate.

Layer additions, don't regenerate everything. For an existing feature where controllers and routes already exist, run with --only-entity so you're not fighting the generator over files you've hand-edited. This is the pattern the 4.1.3 fixes most directly support.

Gotchas and Tips

Upgrade to 4.1.3 if you use --only-entity. Two bugs were fixed: entity generation with method C under --only-entity, and default CRUD methods not being skipped when --only-entity was passed. On 4.1.2 and earlier, --only-entity could produce unexpected CRUD scaffolding or fail for method C — meaning the flag was unreliable exactly where you'd rely on it for incremental work. Verify generated output after upgrading and re-run any entities you generated with that flag.

Watch for silent overwrites. Generators write files by path; re-running against an existing entity can clobber hand edits. Always run against a clean tree and inspect the diff. If the command supports confirmation prompts, don't blindly accept them in scripts.

Config cache will bite you. If you edit the generator config and behavior doesn't change, run php artisan config:clear (and config:cache again if your environment uses it). Same applies to stub path changes.

Published stubs drift from package stubs. When you upgrade the package, upstream stub improvements won't reach you because your published copies win. Diff your stubs against the vendor originals after each minor upgrade, or you'll miss fixes.

Generated code is a starting point, not a review substitute. The generator cannot know your database engine constraints, authorization rules, or validation nuances. Always review migrations for column types/indexes and controllers for authorization before merging.

Method C + --only-entity on older versions is a known trap. If you're pinned below 4.1.3, avoid combining those two options — generate with defaults and delete the CRUD files manually instead.

Debugging a bad generation. Re-run in a scratch branch with the same flags, then compare against the package's own test fixtures in vendor/ronasit/laravel-entity-generator/tests — the tests are the most precise documentation of what each flag combination should produce.