Download the PHP package kerroldj/laravel-migrate-fresh-table without Composer

Laravel Migrate Fresh Table

migrate:fresh-table, but scoped to one table (or a chosen, ordered set) instead of wiping the whole database.

Sometimes you need to rebuild a single table from scratch — reset a corrupted pivot, reapply a changed schema during development, or re-provision one table per tenant — without nuking everything else. This package does exactly that, safely:

• 🎯 Scoped — drop & recreate one table or an ordered list, not the whole DB.
• 🔗 Foreign-key aware — inspects the live schema, reports every parent and child relationship with the rows that would be orphaned, and asks first.
• 🌊 Cascade or data-only — --with-related freshes a table plus its whole dependent tree; --data-only empties the rows and keeps the schema.
• 🧩 Pluggable — choose how a table is rebuilt: re-run its migration, or rebuild from an explicit Blueprint. Register your own strategy too.
• 🏢 Multi-connection / multitenant — target one connection, iterate a list, or resolve tenant connections dynamically. PostgreSQL search_path aware.
• 🧪 Safe by default — confirms before running in protected environments (configurable), plus --dry-run, --pretend, and a transaction so a failed run rolls back instead of half-dropping.
• 🪝 Hookable — lifecycle events and global before/after callbacks.

Works across MySQL/MariaDB, PostgreSQL, SQLite and SQL Server on Laravel 12+ and PHP 8.2+.

Example — a --with-related --data-only --dry-run preview showing the foreign-key impact report and the resolved plan before anything is touched:

Installation

The service provider is auto-discovered. Publish the config file:

This creates config/migrate-fresh-table.php.

Quick start

How it works

For each target table the command:

1. Inspects the live schema on the resolved connection to find every foreign key that touches the table — both the parents it references and the children that reference it.
2. Prints a foreign-key impact report (always).
3. Asks what to do (unless --force, --dry-run, or --pretend) — when dependents exist you can fresh only the target, or cascade to its dependents.
4. Drops the target table(s) — children first — detaching any foreign keys that block the drop, then recreates them — parents first — using the selected strategy, and restores constraints. On PostgreSQL and SQL Server the whole drop/recreate runs in a transaction, so a failure rolls everything back instead of leaving the database half-dropped.
5. Optionally re-seeds.

Drop/recreate ordering is dependency-safe: tables are dropped children-first and recreated parents-first. (With --tables=a,b,c you supply the order yourself — a is a parent of b is a parent of c.)

The foreign-key impact report & prompt

• The table lists every dependent that references the target, A–Z, with the number of rows that actually point at it (FK not null) — the rows a fresh would orphan. Parent tables the target references are shown separately and are not modified.
• When dependents exist you get the three-way choice above; picking [1] is the same as --with-related. With no dependents it's a simple yes/no.
• In a protected environment (default production) you are first asked “Do you really wish to run this command?”; other environments skip straight to the foreign-key prompt. See Safety notes.
• --force skips every prompt (and is required to run non-interactively in a protected environment). --dry-run prints the report and plan, then stops. --pretend prints the SQL without running it. The report is recomputed per connection / tenant.

Freshing dependent tables (--with-related)

By default only the table(s) you name are freshed; tables that reference them keep their rows, which then point at records that no longer exist. Pass --with-related to also fresh every table that (transitively) references the target, in dependency-safe order:

The command resolves the full dependency closure, drops children-first and recreates parents-first, detaching and restoring foreign keys as needed — including circular references. On PostgreSQL and SQL Server the whole run is wrapped in a transaction, so any failure rolls everything back rather than leaving the database half-dropped.

A cascade can touch a lot of tables and wipes their data. Preview with --dry-run first and take a backup.

If one migration file creates several tables (e.g. users + password_reset_tokens + sessions), the command treats the migration as the unit: it drops those sibling tables together and re-runs the file once, so recreation never collides with a leftover table.

Clearing data only (--data-only)

Sometimes you don't want to rebuild structure at all — you just want to empty the tables. --data-only deletes rows instead of dropping/recreating, leaving every table, column, index and constraint exactly in place:

Rows are deleted children-first (so no foreign key is violated) inside a transaction. Because it never drops a table or re-runs a migration, --data-only works cleanly even on schemas with bundled migrations, circular foreign keys, or columns added by later ALTER migrations — cases where a structural drop/recreate is hard or impossible.

Strategies (customizable rebuild logic)

How a table is recreated after it's dropped is decided by a strategy. Two ship out of the box, and you can register your own.

1. migration strategy (default)

Re-runs the migration(s) that build the table. It auto-detects the owning migration by scanning your migration paths for Schema::create('<table>', …). If auto-detection isn't reliable for a table, add a manual override:

2. schema strategy

Recreates the table from an explicit Blueprint callback — handy when no single migration cleanly owns a table:

Select it per run or per table:

3. Your own strategy

Implement the contract and register it:

Custom strategies are resolved through the container, so you may type-hint dependencies. You can also swap the migration resolver itself by binding Kerroldj\MigrateFreshTable\Contracts\TableResolver.

Multi-connection & multitenancy

--all-connections iterates the static list plus anything returned by a dynamic tenant resolver:

The resolved connection is always used explicitly — the package never assumes the default connection — and the foreign-key report runs independently per connection.

PostgreSQL schema awareness

The search_path is set for the duration of the run and restored afterward, so the same table name in different schemas can be freshed independently.

Command reference

Events & hooks

Listen to lifecycle events (each carries connection, table, schema):

Or use global callbacks, fired once per connection:

Safety notes

• Protected environments (by default production) ask you to confirm before anything is dropped — an interactive run prints Application is in the [production] environment. then asks “Do you really wish to run this command?”. In any other environment (e.g. local) it runs without that question. Configure the list in config/migrate-fresh-table.php:

• --force skips the confirmation, and is required to run non-interactively (e.g. in CI) within a protected environment — otherwise the command refuses.
• --dry-run and --pretend are always allowed since they never mutate.
• The foreign-key impact report is always printed, and you are always prompted in interactive mode unless --force.
• If a migration can't be resolved, the command fails loudly with a message telling you to add an overrides entry or switch the table to the schema strategy.

Testing

The suite defaults to an in-memory SQLite database. Because every developer has a different local setup, it also reads a .env from the package root — copy the example and point it at your database:

DB_CONNECTION accepts sqlite, mysql, mariadb, pgsql, or sqlsrv (postgres/postgresql and mssql/sqlserver work as aliases). Real environment variables override .env, so a one-off run is also fine:

License

The MIT License (MIT). See LICENSE.