Laravel Migrate Recreate Laravel Package

Product Decisions This Supports

• Developer-environment reset workflow. Wraps migrate:rollback + migrate into one artisan call so local reset is a single step instead of a two-command sequence people get wrong (wrong batch, forgotten --step, stale state).
• CI/test determinism. Provides a repeatable "return to known schema state" step before seeders or a test suite, which is a pipeline-reliability decision, not a feature decision.
• Build vs. buy (the actual decision). This is a thin wrapper. The question is not "is it good" but "does our team need a dependency for ~10 lines of command logic" — the honest answer is often a composer run script or a project-local command instead.
• Migration hygiene signal. Adopting it is a small bet that your down() methods are meaningful and worth running; if they are, that also argues for investing in migration rollback quality as a team standard.
• Onboarding/DX. Lowers the command surface a new engineer must learn to get a working local DB.
• Out of scope for roadmap. This is internal tooling. It should not appear on a customer-facing roadmap, and it should never be in the production dependency set — dev/test only.

When to Consider This Package

Consider adopting when:

• Your migrations have non-trivial down() logic — dropping views, Postgres extensions/functions/triggers/partitions, revoking grants, cleaning object storage — that a table drop would not faithfully reproduce.
• The rollback→migrate cycle is a frequent, error-prone manual step in local dev or CI.
• You can pin it exactly, require it under require-dev, and keep it out of production images.
• You're comfortable with a single-maintainer utility dependency in the dev/CI supply chain.

Look elsewhere or skip when:

• php artisan migrate:fresh --seed already covers you. For the large majority of Laravel apps it does, with zero added dependencies.
• Your down() methods are empty stubs — then rollback-and-migrate is strictly slower than dropping tables, and the package adds nothing.
• You need production-safe migration orchestration, zero-downtime/online schema change (gh-ost, pt-osc), or rollback gating — entirely out of scope; this is a dev convenience, not a deployment tool.
• Your dependency policy is minimal-dependency or requires audited changelogs — see the v2.1.0 caveat below.

Release-specific caveat for v2.1.0: the only artifact is a full-changelog compare link (2.0.0...v2.1.0) with no release notes. It is a minor bump within 2.x, so no breaking change is signalled, but nothing is documented either. Treat the upgrade as unverified: read the commit diff, pin the exact version, and validate against a scratch database before rolling it into shared CI.

How to Pitch It (Stakeholders)

Executives: No product impact and no roadmap commitment. This is an internal developer-tooling micro-package that bundles two existing artisan commands into one; adopting or skipping it changes nothing a customer sees. Cost is effectively zero. The only real risk is a small third-party dependency and a single maintainer in the dev/CI toolchain — acceptable if pinned and dev-only, and avoidable entirely by writing a two-line script ourselves.

Engineering: v2.1.0 is a minor release off 2.0.0; the published notes contain only a compare link, so there is no stated breaking change but also no changelog to audit — pin the version and review the diff before upgrading. Functionally it's a convenience wrapper around rollback-and-migrate. The decision rule: adopt only if you can name a migration where dropping the table is not equivalent to running down(). If you can't, migrate:fresh is the correct answer and this is a dependency you don't need. If you can, take it as a require-dev dependency, keep it out of production images, and wire it into the CI reset step explicitly rather than relying on the default command behavior.