- Is roslov/migration-checker-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle built around Doctrine Migrations, not a Laravel package. It registers through the Symfony kernel and dependency injection container and inspects Doctrine migration files. Laravel uses Artisan migrations and its own schema builder, so there is no drop-in path between the two stacks.
- How do I install and enable migration-checker-bundle in a Symfony app?
- Install it as a development dependency with composer require --dev roslov/migration-checker-bundle. Register the bundle in config/bundles.php, or let Symfony Flex handle it if a recipe exists. Then run the checker's console command in your local workflow and CI job. Confirm the declared PHP, Symfony, and doctrine/migrations constraints in composer.json first, because the release notes do not list them.
- Can I use roslov/migration-checker-bundle in a Laravel project?
- Not without writing and owning a bridge. Symfony bundles rely on kernel auto-registration and compiler passes, and these checks read Doctrine Migrations metadata, while Laravel has neither the bundle system nor Doctrine Migrations. Bridging that turns a cheap dev dependency into internal code you maintain forever, which is a poor trade for lint-tier tooling. Ask the author whether a Laravel-native adapter exists before investing further.
- What should Laravel teams use instead to catch pending migrations in CI?
- Use Laravel's own tooling: php artisan migrate:status lists pending migrations, and recent Laravel versions exit non-zero when any are pending, though you should verify the behavior in your exact version. For schema drift, wrap that in a small custom Artisan command that runs in CI and fails the build. Because you own that command, keep it tiny and test it against your real migration corpus. That delivers the same pre-deploy safety without a Symfony-to-Laravel bridge.
- What PHP, Symfony, and doctrine/migrations versions does 1.0.0 support?
- The 1.0.0 release notes do not state them, so treat this as unverified until you read the composer.json in the tagged release. Check the PHP floor, supported Symfony majors (5.x, 6.x, 7.x), and the doctrine/migrations range against your CI images. Pay particular attention to whether the bump dropped a PHP or Symfony version you still run, which is a common and quiet 1.0.0 change.
- What changed between 0.5.0 and 1.0.0, and are there breaking changes?
- The 1.0.0 release bundles a version bump with PR #36, described only as a code refactor, and there is no UPGRADE.md or breaking-change callout. A refactor landing alongside the 0.5.0 to 1.0.0 transition is exactly the shape of a release that changes check semantics without documenting it. Review PR #36 for changed predicates and thresholds rather than just moved files. Until then, treat 1.0.0 as behaviorally unverified rather than as a routine bump.
- Should I require ^1.0 or pin 1.0.0 exactly?
- Pin 1.0.0 exactly in a branch and do not float the caret range yet. Install 0.5.0 and 1.0.0 side by side against the same fixtures, ideally a replay of your real migration corpus, and diff the findings, severities, and exit codes. Any delta is a behavior change that must be explained by the refactor or escalated upstream. Widen the constraint only after that comparison comes back clean.
- What exactly does the checker validate in CI, and does it fail the build?
- It is designed to detect pending Doctrine migrations, entity changes with no matching migration, and missing migration files. Findings are surfaced through console output, and the intent is a non-zero exit so CI fails early rather than at deploy time. The release notes do not document the exact exit codes or command signatures, so verify both against your pipeline before relying on it as a gate.
- Does it fail open or fail closed when a migration file cannot be parsed?
- That behavior is not documented, so test it explicitly with malformed or unparseable migration fixtures. Fail-open is the dangerous mode here, since a schema check that silently passes gives false confidence in CI. Run the checker against a deliberately broken file and confirm it errors rather than exits clean. If it fails open, add a wrapper that treats missing output as a failure.
- Who maintains the package, and is it safe to add as a dev dependency?
- It appears to be maintained by a single author, @roslov, who opened all three PRs referenced in the release notes. That is a real bus-factor risk for a dependency that gates your deploy pipeline. The mitigating factor is scope: it is developer and CI tooling rather than a runtime dependency, it holds no state, sits outside the request path, and its worst-case failure is a red pipeline. Pin the version, keep it in require-dev, and have a fallback check ready.