Laracrate Laravel Package

Getting Started

Laracrate is a scaffolding/code-generation package: you describe a resource once and it emits the Laravel files around it (model, migration, form request, controller, routes, and typically views/tests). The day-to-day value is not the first generation — it is that every subsequent resource in the project comes out shaped the same way.

Minimal path:

1. composer require edulazaro/laracrate (dev dependency is usually the right call unless you generate at runtime).
2. Publish the config and the stubs (php artisan vendor:publish) and commit both. They are the seam you will actually live in.
3. Read the config file top to bottom before generating anything — namespace/path targets, stub set, and overwrite behaviour are almost always configurable there, and discovering that after you have hand-edited twenty generated files is painful.
4. Scaffold exactly one throwaway resource end-to-end, run the migration, hit the routes, then delete it.

Do the throwaway resource first and commit the generated output unmodified on a scratch branch. That commit is your reference point for every future regeneration diff, and it tells you immediately whether the 2.1.0 stubs assume conventions (naming, directory layout, auth) that your app does not follow.

First real use case: a single CRUD resource that already has a migration and model in place — generate around the existing table rather than letting the package own the schema, so you find out early how it behaves when it is not in full control.

Implementation Patterns

Generate on a branch with zero hand edits, then commit. The single most important habit: one commit that is pure generator output, a second commit that is your edits. Regeneration later becomes a readable diff against commit one instead of an archaeology exercise. Never mix generated and hand-written changes in the same commit.

Treat the stubs as project source. Publish them, commit them, customize once — your base controller class, your API resource conventions, your declare(strict_types=1) header, your company's pagination defaults. Every developer then gets the same output regardless of who runs the command. This is the main lever for leverage: the package stops being a novelty and becomes your team's file template.

Wrap it in a project command. A thin php artisan app:make-resource that calls the package and then runs Pint, appends the route, and registers the policy is worth the twenty minutes. It gives you one entry point to change when the package's API shifts, and it stops people from memorising flags.

Run static analysis on the generated output in CI. Generated code drifts silently; PHPStan/Larastan on the whole app/ tree catches it. Same for Pint — generated files that are not style-clean pollute every later diff.

Keep generation and migration ordering deliberate. Generate in dependency order (parents before children) or you will spend time reordering timestamped migration filenames by hand. If the package emits multiple migrations per run, check the ordering before migrate.

For existing apps, generate into a namespace that is yours. Point the config at App\Domain\Billing\... rather than App\Models/App\Http\Controllers so generated code has an obvious home and you can tell at a glance which files are still pristine.

Gotchas and Tips

• Overwrite semantics are the trap. Most generators overwrite or skip based on a flag, and the default is not always what you expect. Find the flag, put it in your wrapper with an explicit value, and never let anyone run the bare command against a resource they have already edited. If there is a dry-run, make it the default in your wrapper.
• $fillable and validation rules are guesses. Generated mass-assignment and FormRequest rules describe the column types, not your domain. Review every generated request before it reaches a controller — this is where injection-shaped bugs hide.
• N+1 on generated index pages. List views from generators almost never eager-load. Add with() relationships yourself, or you will find it in production under load rather than in review.
• Pluralisation and route-model binding. Resource names that are irregular, compound (LineItem, UserProfile), or already plural are the classic source of broken bindings and mismatched route keys. Test the show/update routes on the throwaway resource, not on a real one.
• Stub drift across upgrades. 2.1.0 is a minor bump over 2.0.1, so on semver terms nothing should break — but if you have published and customized stubs, the package's shipped stubs have changed and your copy has not. After upgrading, re-publish to a temp path and diff against your committed stubs before deciding whether to adopt the changes. This is the main upgrade cost of the package and the reason to pin the version in composer.json and upgrade deliberately rather than on composer update.
• Check the changelog for generator-output changes first. With a customized stub set, the interesting question is never "does the library still boot" — it is "did the emitted files change shape". Diff a generated resource before and after the bump; that answers it faster than reading commit messages.
• Debugging a bad generation is almost always config resolution, not the generator: dump the resolved config (php artisan tinker or a config dump) to confirm namespace and stub paths point where you think. Relative paths in published config files resolve from the app root, not from config/.
• Extension points to prefer: published stubs > published config > subclassing/overriding the command > patching vendor/. If you find yourself editing vendor/, you have found a bug worth reporting or a reason to fork.