- How do I install barryvdh/laravel-migration-generator?
- Install it as a development dependency with composer require --dev barryvdh/laravel-migration-generator, then optionally publish its config file. Point it at a named database connection and run the Artisan command from your project root. Be aware that it has a hard transitive dependency on doctrine/dbal, which is the most common install failure on modern Laravel, so verify the resolved constraints with a quick spike.
- Should this package go in require-dev or require?
- Put it in require-dev and pin the version. It is a development-time scaffolding utility, not a runtime library, so it should be absent from production artifacts and deployment pipelines. Keep it out of anything that ships to production.
- Which Laravel and PHP versions does this package support?
- Do not trust the README for compatibility. The repository is archived and has no compatibility path for future Laravel or PHP majors, so verify the resolved composer.json constraint plus doctrine/dbal against your target versions with a spike. Confirm the actual command and behavior with php artisan help in your installed version.
- What Artisan command generates migrations from my database?
- The command name drifts between the package description and the developer walkthrough: generate:migrations versus migrate:generate. This is evidence of version fragmentation, so confirm the real command empirically against php artisan help rather than by reading the README. Pin the version you validate so the command stays stable for your team.
- Does it generate foreign keys, indexes, and enums correctly?
- For conventional schemas it translates tables, primary and foreign keys, indexes, and enums into Laravel schema builder calls. Fidelity is the real question: the acceptance bar should be a reviewed draft baseline, not a byte-exact replica. Review the generated schema diff before committing anything.
- What database objects does it not support?
- Views, stored procedures, triggers, partitions, partial indexes, generated columns, check constraints, custom types, spatial types, and database-specific defaults are approximated or silently dropped. That silent omission is a correctness risk that can surface later as production schema drift. Identify which schema objects exist beyond plain tables and decide who hand-authors those.
- Can I run it against a production database?
- Do not point it at a live primary. Use a read-only replica of the real schema and generate into a quarantine path such as database/migrations/imported so unreviewed files are visibly distinct from curated migration history. A misconfigured connection pointed at a live primary is a real blast-radius risk.
- How do I handle foreign key ordering problems?
- Foreign-key cycles can cause replay failures when the generated migrations run in order. Treat the output as a draft baseline and review ordering and constraints manually before committing. Hand-edit or split migrations where cycles appear, and validate by replaying against a clean database.
- Is this package maintained, and what are the risks?
- The repository is archived, has around 246 stars, zero dependents, and no upstream security triage. There is no compatibility path for future Laravel or PHP majors, so treat archived status as an accepted, time-boxed risk rather than something to engineer around. Decide in advance whether you will fork or vendor it internally if a PHP upgrade breaks it, and name that owner.
- What is the alternative for ongoing schema management?
- This package is a one-shot bootstrap, not an ongoing synchronization tool. Generate, review, and commit a baseline, then hand schema ownership to Laravel's native schema:dump and schema-diff tooling for steady state. If someone asks for ongoing synchronization, redirect them to those native tools instead of re-running this package.