- Is hackzilla/doctrine-migration-pruner-bundle a Laravel package?
- No. It is a Symfony bundle, indicated by its Bundle suffix, its dependency on symfony/framework-bundle, and registration through bundles.php. Laravel has no bundle abstraction, so this is not a drop-in Laravel package.
- What does this Doctrine migration pruner actually do?
- It deletes old Doctrine migration files whose versions are already applied and superseded by a baseline or squashed migration. The aim is to keep the migrations directory tidy and reduce clutter in deployment or schema-build steps. The underlying logic is small and not tied to Symfony.
- Does Laravel use Doctrine migrations?
- No, not by default. Laravel ships its own migrator over database/migrations/*.php and tracks applied migrations in its own migrations table. Doctrine usually appears in Laravel only as doctrine/dbal for column introspection. Using Doctrine migrations in Laravel requires a third-party bridge.
- Can I install hackzilla/doctrine-migration-pruner-bundle in a Laravel app?
- Not practically. You would need a compatibility shim for Symfony's dependency injection container, console wiring, and bundle extension conventions. That effort far exceeds the value of pruning a migrations directory, and Laravel's native tooling covers the common case.
- What is the Laravel equivalent of pruning old migrations?
- Laravel's first-party equivalent is schema:dump with the --prune option. It dumps the current schema and removes existing migration files, giving you a squashed baseline without a third-party bundle. For most Laravel teams this is the safer and simpler choice.
- How do I prune migrations in Laravel without this package?
- Run php artisan schema:dump --prune after confirming every environment has applied the migrations you plan to delete. The command writes a schema dump and prunes the migration files so fresh installs build from the dump. Do it on a clean branch or with a backup first, because deleting migration files is destructive.
- Is it safe to delete already-applied migration files?
- Only when the deleted versions are applied in every environment and a squashed baseline exists for fresh installs. Lagging environments, ephemeral preview databases, and new developer machines can break if they still need those migrations. You also lose the normal rollback path for the pruned versions.
- What are the risks of using this package in production?
- The main risks are destructive semantics and low downstream validation. The package deletes files from the repository working tree, it has a single maintainer, very few stars, and no visible security disclosure process. Its Symfony 4 and 5-era constraints may also fail to resolve against current PHP 8.3 and Symfony 7 stacks.
- Does this bundle support Laravel 10, Laravel 11, or Laravel 12?
- No. It is a Symfony bundle and does not target Laravel 10, 11, or 12. Even for Symfony, verify composer.json against your PHP, symfony/framework-bundle, and doctrine/doctrine-migrations-bundle versions. If no maintained release supports your stack, that alone disqualifies it.
- Should I port the pruner concept to an Artisan command or use native tooling?
- Only if Laravel's native schema:dump --prune is insufficient for your workflow. A port would be greenfield work of roughly 100 to 200 lines plus tests: a migrations:prune command, a dry-run default, a force flag, and a config entry for the baseline migration. The original logic is small, so porting is feasible, but installing this bundle in Laravel is not. If your team is genuinely Doctrine-centric, evaluate a maintained Laravel-Doctrine bridge before writing a custom pruner.