Weave Code
Migrations Laravel Package
laravel-doctrine/migrations
Laravel Doctrine Migrations integrates Doctrine's migration library with Laravel, providing a service provider, publishable configuration, and Artisan commands to run, roll back, and inspect database migrations in Laravel Doctrine applications.
Integration with Doctrine2's migrations package for Laravel
Frequently asked questions about Migrations
- What is laravel-doctrine/migrations and what does it do?
- It is a thin adapter that integrates Doctrine2's migrations library with Laravel. It registers the Doctrine Migrations console commands into Laravel's Artisan kernel, publishes a configuration file, and bridges your Laravel database connection config into a Doctrine DBAL connection so the migrator runs against the same database your app uses. It does not own your schema model — doctrine/migrations does that, and the ORM mapping metadata supplies the diff source. It is a bridge dependency whose main blast radius is your deployment pipeline, not your runtime request path.
- How do I install laravel-doctrine/migrations?
- Install it with Composer via composer require laravel-doctrine/migrations; the service provider is auto-discovered in Laravel. Then publish the configuration file with the vendor:publish command and point it at an existing database connection. Most teams are productive in under a day — the friction is not installation but getting the schema-diff workflow right.
- Does laravel-doctrine/migrations support Laravel 12 and Laravel 13?
- Version 3.4.4 is a compatibility patch that widens the illuminate/* and laravel/framework constraints and adds CI coverage for Laravel 13, so the existing code paths are proven on the new major. If your application is on Laravel 11 or 12, 3.4.4 is essentially a no-op and the upgrade can be deferred to a normal dependency-refresh cadence. There are no new commands, no config surface changes and no documented breaking changes in that release.
- Do I need Doctrine ORM to use this package, or can I use it with Eloquent?
- This package is only a fit if Doctrine is already your persistence layer; it is a bridge dependency, not a standalone migration tool. It does not own the schema model — doctrine/migrations does, and the ORM metadata supplies the diff source. If your team is on Eloquent, adopting this package means adopting Doctrine ORM, DBAL and the Unit of Work mental model, which is a platform decision rather than a package decision. There is no partial adoption: you either run Doctrine as the schema authority or you do not use this package.
- Which Artisan commands does laravel-doctrine/migrations add?
- The package registers the Doctrine Migrations console commands into Laravel's Artisan kernel, so you work with commands such as doctrine:migrations:status to inspect state, doctrine:migrations:migrate to run migrations, doctrine:migrations:rollback to revert, and doctrine:migrations:diff to generate migrations from ORM mapping metadata. It also publishes a configuration file that those commands read. A good first verification step after installing is running doctrine:migrations:status against an existing connection.
- How do I configure the database connection for Doctrine migrations in Laravel?
- After installing, publish the package configuration with vendor:publish and point it at an existing Laravel database connection. The package bridges Laravel's database connection config into a Doctrine DBAL connection, so the migrator operates on the same database your application already talks to. Confirm the wiring by running doctrine:migrations:status before generating or running any migrations.
- Why did doctrine:migrations:diff generate a destructive migration?
- Diff derives migrations from ORM mapping metadata, so mapping accuracy and metadata cache state directly determine whether generated migrations are correct or quietly destructive. Stale metadata caches, mapping drift, or entities that are not mapped the way you expect will produce drops and alters you did not intend. Review every generated diff before running it, and add a diff-in-CI check that fails on unexpected destructive operations. Pruning a generated file to an empty or idempotent baseline is also a common technique when adopting the package against an existing schema.
- Can I run Laravel's native migrations alongside Doctrine migrations?
- Running both against the same schema is the single most common failure mode for this package. Pick one owner for the migrations table and one owner for DDL rather than letting both systems apply changes. If you are moving off Laravel migrations, treat it as a one-time baseline: freeze native migrations, tag the last one, point the Doctrine connection at the existing database, and generate an idempotent baseline instead of a gradual conversion.
- How should I run Doctrine migrations in production during a deploy across multiple instances?
- Migrations run in your deployment pipeline, so define a concurrency story for multiple app instances before you need it — typically a single deploy step or a lock so only one process migrates. Be aware that MySQL and Oracle DDL is non-transactional, so a failed migration can leave a partially applied schema and rollback is not a safety net for DDL on those engines. A diff-in-CI check that fails on unexpected destructive operations is worth more than a post-failure rollback plan.
- Is laravel-doctrine/migrations actively maintained, and how risky are its dependencies?
- The project has a small contributor base and an event-driven release cadence, with releases clustering around Laravel majors, so the bus factor is genuinely low for a package sitting in the deploy path. Direct patch releases are low risk, but the real backward-compatibility surface lives in doctrine/orm and doctrine/dbal minor releases, so track the transitive graph rather than the wrapper. Decide who owns the DBAL and ORM version-bump decision and gate it in CI. If you want migrations to stay inside Laravel's own tooling, the alternative is Laravel's native migrations — but that only makes sense if Doctrine is not your persistence layer.
Weaver
How can I help you explore Laravel packages today?