Crud Generator Laravel Package

Getting Started

• Requirements first: v2.0.0 targets PHP 8.2+ and Laravel 10.x+, with official support declared for 12.x and 13.x. Check your composer.json constraints before upgrading—if you're on Laravel 11 you're outside the explicitly tested matrix, so pin the package version and smoke-test the generator rather than assuming parity.

• Install and publish:

  composer require <vendor>/<package>
  php artisan vendor:publish --tag=crud-lang
  php artisan vendor:publish   # inspect the interactive list for config/stub/view tags
  

  The release notes call out crud-lang explicitly and mention "improved publishing tags" generally—run php artisan vendor:publish without arguments once to see the authoritative tag list for your installed version rather than guessing tag names from docs.

• Where to look first: the package config file (publish it into config/ and commit it), then the published stubs directory. The stubs are the real API surface of a generator—everything the package produces is editable text, so read them before reading the source.

• Confirm the command signature: php artisan list (filter for the package namespace) before your first run. Generator command signatures are the most common thing to drift between major versions.

• First use case: scaffold one small, non-critical model end-to-end—migration → Eloquent model → generate the CRUD → open the generated controller, request/validation, and views → run it in the browser. Do this on a throwaway branch. The goal of the first run is not the feature, it's calibrating how much of the output you'd actually keep.

Implementation Patterns

• Treat output as scaffolding, not a dependency. Generate once, commit, then own the code. The package is a build-time convenience; if you find yourself re-running the generator against files you've already customized, you're using it wrong (see Gotchas on --force).
• Model-first workflow. Write the migration and model by hand (relationships, casts, indexes, $fillable), then generate. The generator infers validation from column names and types, so a well-specified schema produces better rules than editing rules after the fact.
• Review the generated validation as a first pass, never as final. v2 auto-detects email, integer, numeric, uuid, and date. Treat that as a lint, not a spec—layer in unique:, exists:, max:, nullable, and confirmed by hand.
• Route Model Binding is now the default in generated controllers. Lean into it: type-hint the model in controller methods, use $this->authorize() / policies against the bound instance, and let 404s come from the binding. If your app uses UUIDs or slugs, set getRouteKeyName() on the model so generated show/edit/update/destroy methods work unchanged.
• API work: the new API Resource output in toArray() makes the generator viable for JSON endpoints, not just Blade. Generate, then move the toArray() body into a dedicated Resource class if you need conditional relationships or per-endpoint shaping—don't let one toArray() serve both an index and a detail endpoint.
• Localization: publish crud-lang, set app.locale, and add your own locale files alongside en/es rather than editing the shipped ones. Generated stubs should reference translation keys—if you find hardcoded English in generated views/controllers, that's a stub customization worth making once and committing.
• Frontend stubs: Bootstrap and Tailwind variants are now standardized and consistent. Pick one, publish it, and delete or ignore the other so nobody accidentally generates a mismatched layout. The generated layout still needs your asset pipeline (npm run dev) to be useful.
• Customize via stubs, not forks. If your team uses a base controller, a form-request class per operation, or a specific view namespace, edit the published stubs once. That's the intended extension point and it survives package upgrades far better than patching generated files repeatedly.
• CI: the package now ships an Orchestra Testbench suite and correct exit codes, so you can assert generator behavior in your own pipeline—e.g. a job that runs the generator against a fixture schema and fails on non-zero exit. Keep that smoke test shallow; you're verifying the tool works in your environment, not re-testing the package.

Gotchas and Tips

• 2-space indentation is a repo-wide change. v2 standardized source and stubs to 2 spaces. If you published stubs under v1 and committed them, your stubs and the new defaults now disagree. Re-publish to a temp directory, diff against yours, and merge deliberately—don't blind-overwrite, and check that Pint/PHP-CS-Fixer config doesn't reformat generated output back to 4 spaces on every commit.
• Re-publishing overwrites silently. vendor:publish on an existing target either no-ops or prompts depending on tag and flags; --force will destroy local stub customizations. Always publish to a scratch path first, or keep stubs under version control so the diff is visible.
• Route Model Binding is a behavioral change for newly generated code. Existing generated controllers are untouched, so you'll have a mix. If you have tests or frontend code asserting {id} route parameters, or controllers doing manual findOrFail($id), new scaffolds will look different. Standardize a direction and note it in your conventions doc.
• Auto-detected validation is heuristic and shallow. Column-name matching misses string length, nullable-ness, foreign keys, enum constraints, and uniqueness. A uuid column will get a uuid rule, but you still need exists: when it's a foreign key, and the model still needs $keyType = 'string' / $incrementing = false. Date detection gives you date where you may want date_format:Y-m-d or after_or_equal:today.
• Exit codes are fixed in v2. If you previously wrapped generator invocations in scripts that ignored status or grepped output for failures, simplify them to plain set -e / exit-code checks.
• Layout generation no longer requires Composer, but generated Bootstrap/Tailwind layouts still require your Node toolchain to build assets. Don't read the fix as "no dependencies."
• Laravel 10 support with 12/13 official and 11 unlisted is an unusual matrix. Verify composer why-not before upgrading Laravel, and re-run your generator smoke test after every framework bump—GeneratorCommand version handling was refactored and is exactly the kind of code that's sensitive to framework internals.
• No relationship/nested-resource generation. Expect to hand-write pivot handling, nested routes, and eager-loading in index actions. This is the most common place teams end up diverging from the stubs—if you do it more than twice, promote it into a stub.
• Debugging a bad generation: the failure is almost always the stub or the schema, not the package. Check the published stub resolves (config paths), confirm the command actually picked up your config (config('...') after config:clear), and verify column types are what you think—doctrine/dbal-free type introspection can report string for columns you expect to be typed.