- What does huangdijia/laravel-migrate-recreate actually do?
- It adds a single Artisan command, migrate:recreate, that lets you roll back and re-run specific migrations instead of refreshing your entire database. Under the hood it is a thin console layer over Laravel's own database-wipe and migrate primitives, so behaviour follows the framework rather than custom logic. It ships one service provider with no config, no published migrations, no middleware, and no runtime request-path code. The practical use case is iterating on one migration in local development while leaving other tables and their data intact.
- How do I install laravel-migrate-recreate?
- Run composer require --dev huangdijia/laravel-migrate-recreate and let Laravel package auto-discovery register the service provider. There is nothing to publish, no config file to copy, and no migrations to run for the package itself. You should then see migrate:recreate listed in php artisan list, which is the quickest way to confirm the install worked. Keep it in require-dev so it never lands in your production image.
- Which Laravel and PHP versions are supported?
- The package targets Laravel applications on PHP 8.x using a relational driver such as MySQL, PostgreSQL, or SQLite. Before adopting, read the composer.json illuminate/* and php constraints for the exact version you install, since the release notes for v2.1.0 are not a reliable compatibility statement. If you need Laravel 11 or 12 support, verify the declared constraints first rather than assuming a minor bump added it. A green CI run on your actual framework version is the fastest confirmation.
- Is laravel-migrate-recreate safe to run in production?
- No. The command is destructive: it drops tables and re-runs migrations, so its blast radius is anyone with shell access to the container. Treat it strictly as a require-dev tool for local development and test harnesses, and confirm your production image is built with composer install --no-dev so the command is absent from artisan list. Check whether your installed version requires --force or an explicit confirmation outside the local environment, and add your own environment guard if it does not. There is no evidence of a built-in safety policy you can rely on.
- What changed in version 2.1.0 and does it break backward compatibility?
- The v2.1.0 changelog is an empty compare link, so the diff is effectively unverified from the release page alone. Read the GitHub compare view between 2.0.0 and v2.1.0 and inspect the file-level changes before assuming a minor bump is a compatibility guarantee. In practice you should constrain the requirement to ^2.1 and let your CI suite validate the upgrade. If you are still on 1.x, treat it as a major break and pin ^1 until you have re-verified the command surface.
- How is this different from migrate:fresh or migrate:refresh?
- migrate:fresh drops every table and re-runs the entire migration set, and migrate:refresh rolls back and re-runs everything. This package is designed for the narrower case where you only want the migration or migrations you specify re-executed while the rest of the database stays as it is. That makes it much faster to iterate on a single schema change during development. Because it is built on wipe-and-migrate primitives, always confirm the exact scope on a disposable database before trusting it with anything you care about.
- Does laravel-migrate-recreate work with schema:dump and schema.sql files?
- The interaction with schema:dump artifacts is not documented, so you should assume nothing. A dump-based project can end up with the tables dropped while schema.sql is left untouched, which produces an inconsistent state that is confusing to debug. If your workflow relies on squashed schema files, test the command on a throwaway database first and record the observed behaviour in your runbook. Many teams simply avoid the combination.
- Can I use it to reset the database in CI test jobs?
- Yes, that is a reasonable fit: it slots in alongside migrate:fresh, db:wipe, and other test-database reset tooling as a per-shard reset step. Before standardising, run it for a couple of weeks and watch for flakiness in your pipeline. Verify behaviour on the specific driver your CI uses, because drop-all semantics differ between SQLite and PostgreSQL with open connections. Also check for conflicts with doctrine/dbal-based tooling and any custom migrate command overrides in your app.
- Is there anything to configure or publish after installing?
- No. The package has no published config, no published migrations, and no queue or event surface to wire up. It is a single service provider registering one console command, which keeps upgrade cost low and config drift at zero. The only ongoing maintenance item is re-checking it when you move to a new Laravel major version. If you need custom behaviour, you would be overriding the command or writing your own rather than editing package config.
- Is the package actively maintained, and what are the alternatives?
- It is a single-maintainer personal package with no vendor backing, no SLA, and no observable security policy, so treat it as community-only support. Check release cadence and issue responsiveness over the last 12 months before committing, and place it in a review-each-Laravel-major bucket rather than a review-each-release bucket. Because it is dev-only, rollback is a one-line composer change with no data migration. Alternatives include migrate:fresh with a targeted subset, db:wipe plus explicit migrate calls, or a small custom Artisan command you control yourself.