#!/usr/bin/env bun
/**
 * Schema migration for whichever backend is configured.
 *
 * Migrations are per-dialect files, not one file rewritten at runtime. Both approaches
 * were on the table; the parallel set won because a runtime translator would have to
 * turn `jsonb`, `timestamptz`, `bigserial`, `::jsonb` casts, `now()` defaults, and
 * `CREATE EXTENSION` into SQLite as a text transformation, and would silently mistranslate
 * the first construct a future migration used that the translator had never seen - on
 * the operator's machine, at migrate time, against their real data. Two hand-written
 * files fail at review time instead, and src/server/schema-parity.test.ts executes the
 * SQLite one and diffs its real introspected shape against the Postgres DDL so the pair
 * cannot drift.
 *
 * Applied-version keys are file basenames, so migrations/0001_*.sql moving into
 * migrations/postgres/ did not orphan databases that had already applied it.
 */
import "../lib/launch-cwd-apply.js";
import { type DatabaseTarget } from "./database-url.js";
export interface MigrationResult {
    backend: DatabaseTarget["kind"];
    applied: string[];
}
/**
 * Apply pending migrations to whatever backend `databaseUrl` names.
 *
 * @param migrationsDir override for the directory holding this dialect's .sql files.
 * Defaults to the dialect subdirectory of the package's migrations/ folder.
 */
export declare function runMigrations(databaseUrl?: string, migrationsDir?: string): Promise<MigrationResult>;