- Does smartteam/migrations-bundle work with Laravel?
- No. smartteam/migrations-bundle is a Symfony bundle: it is kernel-registered, wired through Symfony's dependency injection container, and built on top of Doctrine's migration tooling with a Doctrine ORM/DBAL-managed schema. Laravel's migration system (artisan migrate, Eloquent, its own schema builder) is an entirely separate architecture, and there is no idiomatic way to graft this bundle into a Laravel application. Installing it would mean adopting Doctrine alongside Eloquent, which is a re-platforming decision rather than an integration.
- How do I install smartteam/migrations-bundle in a Laravel application?
- You should not. There is no supported Composer install path for Laravel, no service provider, no facade, and no artisan command integration because the package ships as a Symfony bundle. Even if Composer resolution succeeded, the bundle's commands and services would never be bootstrapped by Laravel's container. Treat this as a stack mismatch, not a configuration problem.
- What does smartteam/migrations-bundle actually do?
- It packages database migrations as a reusable, versioned bundle so the same schema changes can be shared across multiple PHP applications instead of being copied between projects. Migrations are shipped as tagged releases and applied through standard Doctrine migration runners, keeping migration history consistent across apps. The stated goal is predictable upgrades where schema changes travel alongside the code that depends on them.
- Is smartteam/migrations-bundle still maintained?
- No. The last release was 2018-01-18, which is roughly seven years of drift across PHP 7.x to 8.x, Symfony 4 to 7, and Doctrine 2 to 3/4. It has zero stars and zero known dependents, so there is effectively no installed base, no reported issues, and no community pressure to fix compatibility. Expect Composer constraint conflicts and runtime deprecation notices if you try it against a current stack.
- Which PHP, Symfony, and Doctrine versions does smartteam/migrations-bundle support?
- The package dates from the Symfony 2.8/3.x/4.x and PHP 7.x era, and its pinned constraints most likely exclude the current Symfony LTS and Doctrine releases. That makes compatibility blocking even inside a Symfony shop that already uses Doctrine Migrations. Check the declared ranges for php, symfony/framework-bundle, doctrine/migrations, and doctrine/dbal before considering it at all.
- Is it just a fork of zenstruck/migrations-bundle, and is there a maintained alternative?
- Its own description calls it a maintenance project of the old ZenstruckMigrationsBundle, kept alive by a single agency, so yes, it is a low-visibility organizational fork. The important question is whether the diff against upstream is only composer.json metadata or includes unvetted functional code. Upstream DoctrineMigrationsBundle now provides schema diffing into migrations natively, so the capability this bundle added is largely absorbed by the maintained tool.
- Is smartteam/migrations-bundle safe for production database changes?
- The risk profile is unfavorable. Migration generators diff metadata against schema, and a stale generator run against newer Doctrine metadata can emit empty or incorrect diffs, which in migration tooling means destructive DDL in production. That class of package carries asymmetric downside, and with no observable CI or audit trail, 'no known CVE' here means unexamined rather than safe.
- Does smartteam/migrations-bundle have tests, CI, or an audit trail?
- There is no observable test suite, CI configuration, or release audit trail for this fork. Combined with zero stars and zero dependents, you have no signal about regressions introduced since 2018 and no community reporting to rely on. If you must use it, review the full source diff against upstream before trusting it with schema changes.
- What should Laravel developers use instead of smartteam/migrations-bundle?
- Use Laravel's native migration system with artisan migrate and the schema builder, which is framework-integrated and actively maintained. If you need to share schema changes across multiple Laravel applications, distribute them as a Composer package containing plain Laravel migration files and publish them through a service provider, or use Laravel's schema dump and migration squashing features. There is no gap in Laravel that this bundle fills.
- Can I use it in a legacy Symfony app, and should I vendor it instead of requiring it?
- It only fits a pre-existing Symfony 2.8/3.x/4.x application that already runs Doctrine Migrations and actually uses the bundle's added commands. Even then, the safer route is to vendor the source into src/ if the license permits, register the services in your own services.yaml, and own that file set rather than adding an abandoned dependency. Vendoring is cheaper than dependency governance for a bundle this small.