- How do I install oscarafdev/migrations-generator in a Laravel project?
- Install it as a development dependency with composer require --dev oscarafdev/migrations-generator so it never ships to production. On the Laravel 12 line you should also require doctrine/dbal:^4.0, because release 12.0.2 aligns the package with Carbon 3 and Doctrine DBAL 4. Commit the updated composer.json and lock file, then run the generator against a representative database snapshot.
- How do I generate Laravel migrations from an existing database with this package?
- The package provides an Artisan command that inspects your configured database connection and writes migration files into database/migrations. Point it at the legacy database via your .env connection settings, run the command from your local or CI environment, and review the generated files before committing them. Always diff the output against your existing migrations or a schema dump rather than trusting it blindly.
- Which database engines does migrations-generator support?
- It supports MySQL, PostgreSQL, SQLite, and SQL Server, which covers most Laravel applications. MariaDB and PostgreSQL are the engines most likely to show fidelity differences in column types, defaults, indexes, and foreign keys, so test generation explicitly against your target engines and versions. Validate the generated migrations on a fresh database before relying on them.
- Which Laravel and PHP versions are supported by migrations-generator?
- The 12.x line targets Laravel 12 and requires Doctrine DBAL 4, which in turn comes with Laravel 12's usual Carbon 3 dependency. Teams on older Laravel versions should stay on the matching package line rather than forcing the Laravel 12 constraints onto an older application. Check the package's Composer constraints against your Laravel minor and PHP version before upgrading in a branch.
- Why do I get a Doctrine DBAL conflict after upgrading to Laravel 12?
- Laravel 12 typically pulls Carbon 3, which expects Doctrine DBAL 4, while earlier migrations-generator releases on the 12.x line still required DBAL 3. Upgrading the package to 12.0.2 and requiring doctrine/dbal:^4.0 resolves that mismatch for most projects. If another package still pins DBAL 3, you will need to resolve that transitive conflict first or defer the upgrade.
- Can I use migrations-generator in production?
- No. It is a development-time and CI utility for reverse-engineering schemas, not a runtime dependency, so it belongs in require-dev only. Keeping it out of production request paths avoids unnecessary dependencies and surface area in your deployed application. Generated migrations should still be reviewed and validated in staging before they are applied to production databases.
- Does migrations-generator generate foreign keys and indexes, not just columns?
- It generates migration files containing columns, indexes, and foreign keys based on the existing schema it inspects. Fidelity depends on the database engine and on Doctrine DBAL 4 introspection behavior, so some definitions may need manual adjustment. Review index names, foreign key ordering, defaults, and nullable flags carefully, especially for MariaDB and PostgreSQL sources.
- Will migrations-generator handle a large database with many tables?
- Schema size and generation time are the practical limits, since the package inspects every table, index, and foreign key in the target database. Large legacy databases can produce slow runs or noisy output with many migration files to review. Generate against a snapshot, split review across the team, and consider generating in batches by table group if the output becomes unwieldy.
- How should I test generated migrations before merging them?
- Run the package's own regression tests plus project-level schema-generation tests in CI, then apply the generated migrations to a clean database and compare the resulting schema against the source. The 12.0.2 release adds a regression test for schema manager selection, which is a useful control but does not replace validation against your actual schema. Treat staging validation as a required step before merging.
- What are the alternatives to migrations-generator and is it still maintained?
- Alternatives include hand-writing migrations from a schema dump, squashing an existing schema into a single baseline migration, or using other Doctrine DBAL based generators. This package is actively patched for the Laravel 12 and DBAL 4 line, with 12.0.2 fixing the Carbon 3 and DBAL 4 mismatch. Because it is a dev-only tool, ongoing maintenance is mostly dependency hygiene: track Laravel, Carbon, and DBAL major releases and assign an owner for periodic Composer updates.