Model Required Fields Laravel Package

Getting Started

model-fields is a codegen/definition package: you declare a model's fields once (name, type, nullable, default, validation, etc.) in PHP, and the package derives the repetitive artifacts around them — migration columns, casts, $fillable, factory definitions and validation rules. The payoff is proportional to how many models you have; on a single-model project it's overhead.

Minimal path:

1. composer require watheqalshowaiter/model-fields — on 3.2.2 this resolves cleanly against Laravel 13; on Laravel 10–12 you can stay on 3.2.1 or earlier without loss of functionality.
2. Publish the config if the install step offers it (php artisan vendor:publish --tag=model-fields-config) and read it before writing any field definitions — it controls generated paths, stub/namespace choices and default type mappings, and retrofitting those decisions later means regenerating a lot.
3. Read the README's field-definition reference table first, not the source. The type→column→cast→rule mapping is the entire contract of the package; everything else is scaffolding.
4. First use case: a brand-new model. Define the fields, generate the migration, run it, then hit the model through artisan tinker and confirm the generated $fillable/casts actually match what you declared. Do this on a throwaway model before touching anything real.

If you're on an existing codebase, the realistic first use case is a new table, not a refactor. Adopting it for an already-shipped table means either hand-porting the field definition to match existing columns (and accepting the generated output as documentation-only) or regenerating and reconciling the diff manually.

Implementation Patterns

Definition as the single source of truth. The pattern that pays off is treating the field definition as the only place a column's type/nullability/default is written down, and letting migration, casts, fillable and rules all fall out of it. The moment someone hand-edits a generated migration without updating the definition, you've bought yourself a second source of truth and the package is now a liability. Make that a review rule.

Greenfield generation. Define fields → generate migration → run → generate/refresh factory. This is the happy path and where most of the time savings live, especially for wide tables where writing $fillable, casts and 40 validation rules by hand is pure transcription.

Rule reuse in Form Requests. Point your FormRequests at the package's generated rules rather than re-typing them, so a required|max:255 change happens once. Where you need request-specific rules (conditional required_if, per-endpoint sometimes), compose: base rules from the definition, then array_merge the endpoint-specific overrides in the request. Don't fork the definition per endpoint.

Retrofit-by-annotation for existing models. For legacy tables, add the field definition purely to drive validation and casts, and disable/ignore migration generation for that model. You get the validation and cast consistency without a risky schema diff. Do this incrementally, one model at a time, starting with the model that has the messiest validation.

CI drift check. If your team commits generated files, add a CI step that regenerates into a temp directory and fails on diff. This catches "edited the migration, forgot the definition" before merge. This is the highest-leverage integration tip in this assessment — codegen packages rot silently without it.

Pair with factories, not seeders. Generated factory definitions are useful for tests; seeders should stay hand-written because they encode business scenarios, not schema.

Gotchas and Tips

• 3.2.2 is a support-matrix bump only. Just Support laravel 13. No API changes, no deprecations, no new features. It warrants an update to your constraints, not to your code. The practical consequence: if you're moving an app to Laravel 13, this package must be at 3.2.2 or the Composer resolution will block you; conversely, don't bump to 3.2.2 on Laravel 12 expecting anything to change.
• Watch the transitive lag. Laravel 13 support in this package doesn't mean your other codegen/validation/testing packages are ready. When a major-framework bump lands like this, resolve the whole matrix in a branch before committing to the upgrade.
• Generation is one-way. Treat generated migrations as write-once artifacts. Once a migration has run in any shared environment, editing its field definition and regenerating will produce a new migration or overwrite a historical one — depending on config. Never let regeneration touch an already-deployed migration file.
• Type mapping is lossy at the edges. decimal(8,2), enum, json and unsigned variants rarely survive a naive type→cast→rule round trip. Check these three specifically on your first model; every codegen package I've seen has opinions here that differ from yours.
• Rules that can't be generated. unique, exists, confirmed, current_password and anything needing a table name or another field are almost always out of scope for the generator. Plan for a hand-maintained "extra rules" hook and keep it in the same file as the definition so reviewers see both.
• Casts vs. rules drift. A field can be correctly cast and incorrectly validated (or vice versa) and nothing will complain. Assert both in a feature test for your first two models — one test that a valid payload persists with the right PHP type, one that an invalid payload 422s.
• Debugging: when generated output looks wrong, dump the resolved field array before blaming the generator. Nine times out of ten the definition (or a config default for that type) is the culprit, not the template.
• Extension points: the config's type mapping and any custom-field/stub registration are where you adapt the package to house conventions (e.g. always string with explicit length, ULIDs instead of auto-increment). Prefer configuring these over editing vendor stubs — vendor edits die at the next composer update.
• Pin sensibly. ^3.2 is fine if you're on Laravel 13; on older frameworks constrain below the version that dropped support, or Composer will happily resolve you into an untested combination.