Laravel Migrate Recreate Laravel Package

Getting Started

• Install as a development-only dependency where possible: composer require --dev huangdijia/laravel-migrate-recreate. Confirm Laravel auto-discovery registers the service provider, or add it manually if your app disables discovery.
• First check the command surface with php artisan list | grep migrate and run php artisan migrate:recreate --help after installation. The release notes for v2.1.0 only link to the full changelog, so verify the command signature and options locally before relying on them.
• Look first at the package README, any publishable config such as config/migrate-recreate.php, and the command class. If config was published previously, compare it with the v2.1.0 changelog in case defaults changed.
• Start on a disposable local database: create a scratch database, run php artisan migrate:recreate, and confirm it drops/recreates the expected schema and re-runs migrations. Add --seed only if the package’s command exposes that option.
• The primary day-to-day use case is resetting a local or ephemeral database to a known migration state while developing features, debugging migration order, or preparing a clean environment for manual testing.

Implementation Patterns

• Local reset workflow: use migrate:recreate instead of manually dropping tables when migration state is corrupted. Pair it with your normal seeder command if the package does not seed automatically: php artisan migrate:recreate && php artisan db:seed.
• CI/ephemeral database setup: run the command only against disposable databases created for the job. Keep it out of deployment pipelines unless the target database is explicitly disposable.
• Environment guard: wrap usage in scripts that assert APP_ENV is local or testing, and avoid exposing it as a broadly available production command. Consider a custom wrapper command or composer script that checks the environment before invoking it.
• Seeder integration: if the command supports a seeder class or --seed, standardize a local seed set for repeatable demos. If not, keep seeding as a separate explicit step so reset and seed behavior remain obvious.
• Testing: for Laravel feature tests, prefer RefreshDatabase or DatabaseMigrations; use migrate:recreate mainly for manual resets, acceptance environments, or test bootstrap scripts where a full destructive reset is acceptable.
• Composer scripts: add a clearly named script such as "db:reset-local": "php artisan migrate:recreate" and document that it is destructive. This reduces accidental use in the wrong environment.
• Version upgrades: treat v2.1.0 as a minor release pending changelog review. After upgrading, run the command’s --help, re-run it on a scratch database, and check whether config publishing or command options changed.

Gotchas and Tips

• This package is destructive by nature. Confirm the active database connection before running it; a stale .env, cached config, or wrong DB_DATABASE can wipe the wrong schema.
• v2.1.0’s release note is only a full-changelog link, so there is no summarized breaking-change or feature list in the release note. Review the compare diff before upgrading in shared environments.
• Clear cached configuration after install or upgrade: php artisan config:clear and, if applicable, php artisan package:discover.
• Database permissions matter. The command may need rights to drop tables, disable foreign-key checks, or recreate schemas. Failures on MySQL/PostgreSQL are often permissions or foreign-key ordering issues rather than package bugs.
• SQLite behaves differently from MySQL/PostgreSQL around foreign keys and table drops. Test the command against the same database engine your team uses locally.
• Avoid running it while queue workers, Horizon, or long-lived processes hold connections. Stop workers first if schema locks or stale connections occur.
• Debug with php artisan migrate:recreate -vvv and check Laravel logs. If the command is missing, verify package discovery and that the service provider is registered.
• Extension points are typically limited to published config, command options, and overriding the command in your app. Do not fork the package for simple workflow guards; wrap it in a project-specific artisan command or composer script instead.
• Keep the package in require-dev unless you have a deliberate non-production use case that needs it at runtime. Production deployments should use normal migrate workflows.