Eloquent Model Generator Laravel Package

Getting Started

Install the package as a dev dependency — it is a code-generation tool, not a runtime dependency:

composer require --dev pepijnolivier/eloquent-model-generator
php artisan vendor:publish --tag=model-generator-config

The published config/model-generator.php is the first place to look. It controls the namespace models are written to, the target connection, whether to infer relationships from foreign keys, and template paths. Confirm the exact Artisan signature before scripting anything against it:

php artisan list | grep -i model

The canonical first use case is a legacy or externally-managed database you have inherited: tables exist, but no app/Models classes do. Point the generator at that connection and generate the whole set in one pass:

php artisan model:generate --connection=legacy --all

If you already have migrations but want to skip hand-writing boilerplate, generate a single model for one table instead of scaffolding the entire schema — this is the safer daily habit:

php artisan model:generate --table=orders

Read the output file immediately. The value of the package is the $fillable array, $casts, and relationship methods it derives from your live schema — that introspection is what you are paying for, not the file write.

Implementation Patterns

Generate-then-own. Treat generated models as a first draft committed to git, not as artifacts your app regenerates. The generator cannot know your accessors, scopes, domain methods, or custom casts, so overwriting on every schema change destroys work. A workable rhythm:

1. Generate the model into a scratch namespace (e.g. App\Generated) or a temp directory.
2. Diff it against the hand-maintained model.
3. Copy across only the parts you want — usually $fillable, $casts, new belongsTo/hasMany methods.

This gives you schema-driven accuracy without coupling production code to the tool.

Schema-first bootstrapping for a new service. When standing up a bounded context against an existing schema, generate all models, then immediately split them into app/Models/{Domain}/ folders and fix namespaces. Doing the folder restructure before writing any business logic is far cheaper than after.

Relationship inference as a verification tool. Even if you never keep the generated files, running the generator over a schema is a quick way to confirm that foreign keys and indexes actually exist as you expect. If a belongsTo is missing from the output, your FK is missing in the database — a useful smoke test after a migration run.

Pair with migrations in CI, but don't gate on it. A lightweight CI job that regenerates to a temp path and reports a diff (rather than failing) surfaces schema drift: columns added in a migration but never reflected in $fillable. Report, don't fail — legitimate model customisation will always produce noise.

Config-driven generation per environment. Keep separate config values (or pass --connection) for local vs. staging databases. Pointing the tool at a production connection is the single easiest way to overwrite a model with a stale schema.

Gotchas and Tips

• Destructive overwrites. Most generators silently replace existing files. Check for a --force flag and never run the "all tables" command without it against your real app/Models. Version control is your only real safety net here.
• Relationship detection requires real foreign keys. Schema introspection only finds belongsTo/hasMany where FK constraints exist. MyISAM tables, older MySQL setups, and hand-built schemas frequently have none. Add them in a migration if you want the generator to help you.
• Pivot and lookup tables. Expect many-to-many join tables to be generated as full models you don't want. Filter with --exclude/--tables or delete them after generation and add belongsToMany to the parent models by hand.
• Casts and column types. JSON, enum, and date-time handling depend on the driver's type reporting. Verify $casts on json, timestamp, and boolean columns especially — SQLite and Postgres report these differently and casts are where incorrect guesses bite hardest.
• Timestamps and primary keys. Non-standard tables (created_at absent, UUID or composite keys) often need manual correction of $timestamps, $primaryKey, $keyType, and $incrementing. Review every generated model on first run before trusting the defaults.
• Connection and namespace config quirks. Config values are cached; after editing the config run php artisan config:clear. The output namespace must match your PSR-4 autoload map or generated files simply won't resolve — a silent failure that looks like a broken model.
• Extension points. Custom templates (if the config exposes a template path) are the cleanest way to enforce house style — add your base model, declare(strict_types=1), and standard traits once in a template rather than fixing every output. If the package fires events or supports post-generation callbacks, hook formatting (vendor/bin/pint) there.
• Debugging a bad generation. When output looks wrong, the schema is almost always the culprit, not the package. Inspect with php artisan db:table {name} or a direct SHOW CREATE TABLE; confirm the introspector sees the same thing your DB:: connection does.
• Bus factor. With a small star count and zero dependents, treat this as a convenience script, not infrastructure. Keep it in require-dev, never call it from application code or deploy hooks, and be prepared to replace it with a handful of hand-written models if it stops being maintained.