Weave Code
Migrations Laravel Package
doctrine/migrations
Doctrine Migrations is a database schema migration library for PHP, letting you version and track schema changes with a robust CLI and API. It integrates with Doctrine DBAL and ORM to safely apply, roll back, and manage migrations across your projects.
Doctrine Database Migrations Library
Frequently asked questions about Migrations
- Can I use doctrine/migrations in a Laravel application?
- Yes, technically, by registering a Doctrine migrations Configuration object and the library's command classes through a Laravel service provider. However, it creates a second migration system parallel to Laravel's built-in migrations. It is not a first-party Laravel package and has no Laravel-specific documentation or upgrade contract. It makes the most sense when your application already uses Doctrine ORM.
- Does doctrine/migrations replace Laravel's built-in migrations?
- No, it does not extend or replace Illuminate\Database\Migrations. It stands up a separate engine with its own migrations table and CLI commands. Laravel's artisan migrate commands continue to manage Eloquent-owned schema. Running both means two sources of truth, so you need explicit schema ownership boundaries.
- When is doctrine/migrations worth using with Laravel?
- It is mainly worth it when you use Doctrine ORM in Laravel, for example via laravel-doctrine/orm, and want migrations:diff to generate migrations from entity mapping metadata. That diff generation is the package's real differentiator. For Eloquent-first apps it adds a heavier engine, a second version table, and Symfony Console dependencies without replacing work you already do by hand.
- How do I install and configure doctrine/migrations in Laravel?
- Install it with Composer, then register a Doctrine\Migrations\Configuration\Migration\Configuration object and the library's command classes via a Laravel service provider. Configure migration paths, table_storage, all_or_nothing, transactional, and schema_filter explicitly. Community bridges exist, but the integration is bespoke and not supported by Doctrine or Laravel.
- Will doctrine/migrations migrations:diff drop my Laravel tables?
- It can. migrations:diff proposes dropping tables that exist in the database but are absent from Doctrine ORM metadata, so in a mixed Eloquent/Doctrine app an unconfigured schema_filter can generate destructive migrations against Eloquent-owned tables. Treat schema_filter and CI gating as mandatory rather than relying on review discipline. This is the most likely production incident with this setup.
- Does doctrine/migrations work with Laravel 11 and doctrine/dbal 4.5?
- Laravel 11+ removed the DBAL v3 constraint tied to column modification support, freeing DBAL v4, and doctrine/migrations 3.9.8 is the first release showing the 3.9 line is tracking DBAL 4.5. If you are on DBAL 4.5, treat 3.9.8 as the version floor. Laravel 10 and earlier pin DBAL v3, which can force you onto an older migrations line. Always verify the exact constraint combination in a spike.
- Is doctrine/migrations transactional on MySQL?
- Not reliably for DDL. MySQL implicitly commits DDL, so all_or_nothing and transactional provide weaker guarantees than their names imply. A mid-migration failure can leave partial schema applied with no version row recorded. You may need manual reconciliation via migrations:version.
- What is the difference between doctrine/migrations and Laravel migrations?
- Laravel migrations are first-party, Eloquent-oriented, use their own migrations table, and are driven by artisan. doctrine/migrations is framework-agnostic, built on doctrine/dbal and symfony/console, and is designed around Doctrine ORM metadata and diff generation. Adopting it in Laravel stands up a parallel system rather than extending the native one.
- How should I test doctrine/migrations in a Laravel CI pipeline?
- Run migrations against a disposable database in CI and gate destructive diff output before it reaches production. Verify that schema_filter excludes Eloquent-owned tables and that all_or_nothing behavior matches your database's DDL transaction support. Also test rollback and migrations:version recovery paths, because partial DDL failures are realistic on MySQL.
- What are the maintenance and upgrade concerns for doctrine/migrations 3.9.x?
- Release 3.9.8 is a two-PR patch with no new features or breaking changes, mainly fixing a doctrine/dbal 4.5 deprecation. The 3.9 line appears to be a stabilisation branch receiving compatibility patches while 4.0.x absorbs development. Adopting 3.9.x means planning for a known major upgrade with no published migration guide evaluated here.
Weaver
How can I help you explore Laravel packages today?