Migration
A migration file returns an object with up()/down() methods,
each calling Schema directly — Migration's job is tracking which files
have run, running new ones in filename order, and rolling back:
<?php
return new class {
public function up(): void
{
Schema::createTable('users', function (Blueprint $table) {
$table->id();
$table->string('email');
});
}
public function down(): void
{
Schema::dropTable('users');
}
};
Filename convention: YYYYMMDDHHMMSS_description.php — sorted and run in that order.
Methods
Migration::migrate(string $migrationsPath, ?string $context = null): array // names newly applied
Migration::rollback(string $migrationsPath, int $steps = 1, ?string $context = null): array // most-recent first
Migration::status(string $migrationsPath, ?string $context = null): array // name => applied?
Migration::migrate(__DIR__ . '/../database/migrations');
// ['20260808000000_create_changelog_entries_table']
Applied migrations are tracked in a clarity_migrations table, created automatically on
first use — not one of the two setup-owned tables (sessions/caches), just
internal bookkeeping.
Raw SQL and seeds
Migration::runSqlScript(string $path, ?string $context = null): void // splits on ; after stripping -- comments
Migration::runSeed(string $path, ?string $context = null): void // a PHP file returning a callable, invoked with no args
Exporting the live schema
Migration::exportDdl(?string $context = null): string // idempotent CREATE TABLE statements
SQLite and MySQL reproduce the live schema exactly. PostgreSQL has no equivalent facility — its
export reconstructs columns from information_schema only; primary keys, unique
constraints, and indexes are not captured. Re-declare those via Schema after importing,
or use pg_dump directly for a complete Postgres dump.