Implicit Migrations Laravel Package

Getting Started

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

composer require --dev toramanlis/implicit-migrations

Laravel package discovery should register the service provider automatically. Confirm the available commands before doing anything else:

php artisan list | grep -i implicit

Publish the config if the package provides one:

php artisan vendor:publish --provider="Toramanlis\ImplicitMigrations\ImplicitMigrationsServiceProvider"

Then point the config at your model directory (app/Models by default in most Laravel apps) and run the generator against a single model first. The first useful use case is a model you have already written but whose table does not exist yet: define $fillable, $casts, and relationships, generate the migration, review it, then run php artisan migrate. Treat the generated file as a draft scaffold, not as a source of truth.

Implementation Patterns

Model-first prototyping. Write the Eloquent model as you want to use it in code—$fillable, $casts, $table, relationships—then generate the migration from it. This is fastest on greenfield features where the domain model is clearer than the schema.

Baseline generation for legacy apps. For an existing codebase with models but missing or drifted migrations, generate one migration per model, review them, and consolidate into a baseline schema migration. Do not commit the raw output unreviewed; generated ordering and foreign keys will need adjustment.

Change workflow. After altering a model, regenerate or diff the migration rather than hand-editing blindly. A practical loop is:

php artisan <implicit-command> --model=Invoice
# review database/migrations/*_create_invoices_table.php
php artisan migrate

Model discovery scope. Restrict generation to a namespace or path in the config. Generating from every model in a large app at once produces noisy, interdependent migrations; generate by bounded context or feature folder instead.

Relationship handling. belongsTo relationships are the most useful inference point for foreign keys, but verify the generated foreignId(...)->constrained() calls. hasMany and polymorphic relations often need manual morphs() or index additions.

CI guardrail. Once the schema stabilizes, run the generator in a dry-run or diff mode in CI to catch models that have drifted from migrations. This is more valuable than using it to author every migration.

Pair with normal migrations. Keep using hand-written migrations for indexes, data backfills, and production-safe changes. Use the generator for initial table shape and rapid iteration.

Gotchas and Tips

• Casts are lossy. decimal:2, datetime, immutable_date, enums, and encrypted casts do not map one-to-one to column definitions. Always inspect precision, nullability, and defaults.
• Accessors and appended attributes are not columns. Attributes computed in PHP can be mistaken for schema if they appear in $appends or custom casts. Exclude them explicitly.
• $guarded = [] tells you nothing. Models using guarded instead of fillable give the generator little to infer; fill in columns manually or switch to explicit $fillable for generation.
• Foreign key ordering. Generated migrations can reference tables created later. Rename timestamps or split migrations so parent tables run first; circular references need nullable FKs and a follow-up migration.
• Indexes and uniqueness are rarely inferred. Add unique(), composite indexes, and full-text indexes by hand.
• Do not run the generator against production. It writes files and may attempt schema inspection. Keep it local and in CI only.
• Existing table collisions. If a table already exists, the generated Schema::create will fail. Use it for new tables or generate a diff/alter migration if the package supports it; otherwise treat output as reference only.
• Low star count means read the source. With a small package, verify how it maps each cast and relationship in the generator class before trusting bulk output. Pin the version in composer.json.
• Debugging tip: generate for one simple model first, inspect the resulting Blueprint calls, then scale up. Compare generated output with php artisan schema:dump or an existing dump to spot missed columns.
• Extension points: look for a type-map or column-resolver class in the config. If your app uses UUIDs, ULIDs, spatial types, or custom casts, that is where you teach the generator your conventions rather than patching output every time.
• Timestamps and soft deletes. Confirm the generator respects $timestamps = false and SoftDeletes; otherwise you will get stray deleted_at or missing timestamp columns.