- What is kitloong/laravel-migrations-generator used for?
- It is a dev-time Artisan and Composer package that reverse-engineers an existing database into Laravel migration files, including indexes and foreign keys. It is useful for brownfield Laravel adoption, legacy database modernization, schema documentation, due diligence, and onboarding. It should not be treated as a permanent runtime dependency or the ongoing source of truth for application behavior.
- How do I install and run Laravel Migrations Generator?
- Install it with composer require --dev kitloong/laravel-migrations-generator. Laravel auto-discovers the service provider, while Lumen requires manual provider registration in bootstrap/app.php. Configure the database connection in config/database.php, then run php artisan migrate:generate with options such as --connection, --tables, or --ignore.
- Which databases and Laravel versions does Laravel Migrations Generator support?
- It supports Laravel's first-party databases: MySQL, MariaDB, PostgreSQL, SQL Server, and SQLite. Check the package branch, release notes, and compatibility matrix, then pin the version that matches your Laravel and PHP versions. Generated migrations may still carry engine-specific types, collations, index names, and foreign-key names.
- Can I generate migrations for only specific tables?
- Yes, use --tables="table1,table2" to include only selected tables or --ignore="table3,table4" to exclude tables. Pair these with --skip-vendor, --skip-views, and --skip-proc when legacy or vendor objects are out of scope. Review the generated files before committing them to application source control.
- How do I handle an existing production database baseline?
- Do not run generated create-table migrations blindly against a populated production database. Use a deliberate baseline strategy such as a schema dump, migration logging with --log-with-batch=0, --skip-log, or documented manual migration records. Validate the approach on staging or a restored, sanitized dump before touching production.
- How should I test generated migrations?
- Run php artisan migrate:fresh on an empty scratch database, then compare the resulting schema against the source database. Check tables, columns, indexes, foreign keys, views, procedures, collations, and engine-specific features. Add DBA review or schema-drift detection before relying on the generated output.
- Does it generate foreign keys and indexes?
- Yes, it generates Laravel migrations including indexes and foreign keys. Use --default-index-names and --default-fk-names when you want Laravel-style names instead of preserving legacy database naming. Foreign-key ordering and excluded tables can still affect whether fresh migrations succeed.
- Can it handle views, stored procedures, and triggers?
- The package supports views, stored procedures, foreign keys, squashing, custom paths, and migration logging. Use --skip-views and --skip-proc if those objects are out of scope, and confirm trigger and function support for your database. Validate any generated view or procedure migrations separately from table migrations.
- Should I use --squash or per-table migrations?
- Per-table output is more reviewable and easier to debug, which is usually better for a first baseline. Use --squash for a compact baseline when foreign-key complexity is manageable and review can still be thorough. Either way, commit generated files through normal pull request review.
- What are alternatives to Laravel Migrations Generator?
- Alternatives include manually writing migrations, using Laravel schema dumps for existing databases, or database-specific schema export tools. This package is credible open-source tooling with strong GitHub visibility and an MIT license, but it has no commercial support and zero listed dependents. Evaluate maintenance, compatibility, and DBA sign-off for your project.