@vibeorm/migrate 1.3.1 → 2.0.0-alpha.2

package/README.md

@@ -1,95 +1,62 @@
 # @vibeorm/migrate
 
-Migration, introspection, and schema diff toolkit for VibeORM. Handles DDL generation, database introspection, schema comparison, migration tracking, and `.prisma` schema printing.
+> Part of **[VibeORM](https://github.com/vibeorm/vibeorm)** — a type-safe TypeScript ORM for Bun and Node. Prisma-schema or TypeScript-DSL input, a canonical schema IR, a generated client, and a dialect-aware SQL layer over PostgreSQL, PGlite, SQLite and MySQL.
 
-## Installation
+The migration engine: it diffs two schema IRs into dialect-neutral steps, renders those steps as per-dialect DDL, applies them with bookkeeping, and introspects a live database back into IR. It is its own package so that the CLI and tests can run schema changes without pulling in the query runtime, and so every SQL-text decision stays in one reviewable place.
 
 ```bash
-bun add @vibeorm/migrate
+bun add @vibeorm/migrate@alpha
 ```
 
-## Features
+> **Pre-release.** `2.0.0-alpha.x`, published under the `alpha` dist-tag. `npm i vibeorm` still resolves to the stable v1 line.
 
-- **DDL generation** — schema IR to PostgreSQL DDL (enums, tables, constraints, indexes, foreign keys, M:N join tables)
-- **Introspection** — reverse-engineer a live PostgreSQL database into schema IR
-- **Schema diffing** — compute migration operations between two schema versions
-- **Migration runner** — track and apply migrations via a `_vibeorm_migrations` table
-- **Snapshot management** — serialize/deserialize schema IR as JSON for diffing
-- **Schema printing** — convert schema IR back to `.prisma` format
+Most users never install this directly — it ships as a dependency of [`vibeorm`](https://www.npmjs.com/package/vibeorm) and of the generated client. Reach for it when you are writing an adapter or tooling against the runtime.
 
-## API
+## What it does
 
-### DDL
+Three stages, each usable on its own.
 
-```ts
-import { buildDDL } from "@vibeorm/migrate";
+**Diff.** `diffSchemas({ from, to, dialect })` returns ordered `MigrationStep` values — `createTable`, `addColumn`, `alterColumn`, `createIndex`, `addForeignKey`, `createJoinTable`, `dropView` and the rest. Steps carry IR fragments, never SQL text, and are emitted in dependency-safe order. Both sides normalize before comparison, so `diffSchemas({ from: introspect(push(X)), to: X })` is empty: pushing twice is a no-op. There is no rename detection — a renamed table diffs as drop plus create.
 
-const { sql, statements } = buildDDL({ schema });
-// sql: full DDL wrapped in BEGIN/COMMIT
-// statements: individual DDL statements
-```
+**Render.** `renderSteps({ steps, dialect, from, to })` produces the SQL strings for postgres, sqlite (including the table-rebuild recipe for ALTERs sqlite cannot express) or mysql. `describeStep({ step })` gives the one-line human description used in CLI output and refusal messages.
 
-### Introspection
+**Run.** `applyMigrations` executes `MigrationFile`s in order under an advisory lock, recording each in the `_vibe_migrations` bookkeeping table with a sha256 checksum over its statements. Re-applying a migration whose SQL changed is a `VIBE_MIGRATION` error, not a silent divergence. On postgres and sqlite each migration runs inside one transaction with its bookkeeping row; on mysql, where DDL auto-commits, progress is recorded per statement and a re-run resumes from where it stopped. `migrationStatus` reports applied, pending, mismatched and mid-rollback migrations, `rollbackMigration` runs a migration's `downSql`, and `resolveMigration` repairs the bookkeeping table without running SQL.
 
-```ts
-import { introspect } from "@vibeorm/migrate";
+**Introspect.** `introspectPostgres`, `introspectSqlite` and `introspectMysql` read a live database back into `SchemaIR`; `pull` picks the right one for a dialect.
 
-const schema = await introspect({ executor });
-// Returns a Schema IR from a live database
-```
+## push vs migrate
 
-### Schema Diffing
+`push` goes straight from the live database to your schema — introspect, diff, render, apply — with no files kept. It suits prototyping and disposable databases. `generateMigration` plus `applyMigrations` keeps named, checksummed SQL files you can review and replay, which is what shared and production databases need. Details in [docs/migrations.md](https://github.com/vibeorm/vibeorm/blob/master/docs/migrations.md).
 
-```ts
-import { diffSchemas } from "@vibeorm/migrate";
+## Destructive steps
 
-const operations = diffSchemas({ previous: oldSchema, current: newSchema });
-// Returns DiffOperation[] with isDestructive flags
-```
+Every step carries a `destructive` flag: drops of tables, columns, enums and join tables, plus narrowing type changes. `push` refuses to run when any step is destructive unless you pass `acceptDataLoss: true`, and the thrown `VibeError` (`VIBE_MIGRATION`) lists each offending step by description. `generateMigration` surfaces the same information as `MigrationFile.destructive` so callers can require confirmation before applying. Constructs a dialect cannot express — scalar lists on sqlite and mysql, partial indexes on mysql, removing a value from a surviving enum — throw `VIBE_UNSUPPORTED_CAPABILITY` instead of degrading.
 
-### Migration Runner
+## Usage
 
 ```ts
-import {
-  ensureMigrationTable,
-  getAppliedMigrations,
-  applyMigration,
-  removeMigrationRecord,
-  markMigrationApplied,
-} from "@vibeorm/migrate";
-
-await ensureMigrationTable({ executor });
-const applied = await getAppliedMigrations({ executor });
-await applyMigration({ executor, migrationName: "20260101_init", sql, checksum });
-```
-
-### Snapshots
+import { applyMigrations, generateMigration, push, pull } from "@vibeorm/migrate";
+import { toSqlExecutor } from "@vibeorm/runtime";
 
-```ts
-import {
-  saveSnapshot,
-  loadLatestSnapshot,
-  loadSnapshot,
-  saveJournal,
-  loadJournal,
-  generateTimestamp,
-  computeChecksum,
-} from "@vibeorm/migrate";
-```
+const executor = toSqlExecutor({ adapter });
 
-### Schema Printing
+// Prototyping: make the database match the schema.
+const result = await push({ executor, schema, acceptDataLoss: false });
+console.log(result.steps, result.applied);
 
-```ts
-import { printSchema } from "@vibeorm/migrate";
+// Versioned: render a named migration from a diff, then apply it.
+const migration = generateMigration({ from: previous, to: schema, name: "add_posts", dialect: "postgres" });
+await applyMigrations({ executor, migrations: [migration], dialect: "postgres" });
 
-const prismaText = printSchema({ schema });
-// Returns .prisma formatted schema text
+// Introspect the live database back into IR.
+const live = await pull({ executor, dialect: "postgres" });
 ```
 
-### Diff Operation Types
-
-18 operation types: `createEnum`, `addEnumValue`, `removeEnumValue`, `dropEnum`, `createTable`, `dropTable`, `addColumn`, `dropColumn`, `alterColumnType`, `alterColumnNullability`, `alterColumnDefault`, `addUnique`, `dropUnique`, `addIndex`, `dropIndex`, `addForeignKey`, `dropForeignKey`, `createJoinTable`, `dropJoinTable`.
+`SqlExecutor` calls must all reach the same database session — the engine issues `BEGIN`/`COMMIT`, `PRAGMA` and advisory-lock statements through it. Pool-backed executors must pin one connection for the whole operation.
 
-## License
+## Links
 
-[MIT](../../LICENSE)
+- [Documentation](https://github.com/vibeorm/vibeorm/tree/master/docs)
+- [Query API](https://github.com/vibeorm/vibeorm/blob/master/docs/queries.md)
+- [Repository and issues](https://github.com/vibeorm/vibeorm)
+- MIT licensed

package/dist/ddl/drop-order.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Topological ordering for DROP TABLE statements — children (referencing
+ * tables) first.
+ *
+ * postgres never needs this: `DROP TABLE … CASCADE` takes inbound FK
+ * constraints with it. sqlite and mysql have no working cascade for inbound
+ * foreign keys — mysql refuses outright (errno 3730
+ * `ER_FK_CANNOT_DROP_PARENT`, observed live on 8.4 when a fixture switch
+ * dropped `Project` while the also-being-dropped `ProjectMember` still
+ * referenced it). ONE shared implementation, consumed by both renderers —
+ * the LEARNINGS rule: a structural rule is never re-implemented per consumer.
+ */
+import type { NormalizedSchema } from "../normalize.ts";
+/**
+ * Order the tables in `names` so that no table is dropped while another
+ * to-be-dropped table still references it. Tables unknown to `fromNorm` (or a
+ * missing `fromNorm`, or a reference cycle) fall back to the given order —
+ * rendering proceeds and the server reports what it cannot do (dialect
+ * honesty beats silently dropping statements).
+ */
+export declare function orderDropsChildrenFirst(params: {
+    names: readonly string[];
+    fromNorm: NormalizedSchema | undefined;
+}): string[];
+//# sourceMappingURL=drop-order.d.ts.map

package/dist/ddl/drop-order.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"drop-order.d.ts","sourceRoot":"","sources":["../../src/ddl/drop-order.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,iBAAiB,CAAC;AAExD;;;;;;GAMG;AACH,wBAAgB,uBAAuB,CAAC,MAAM,EAAE;IAC9C,KAAK,EAAE,SAAS,MAAM,EAAE,CAAC;IACzB,QAAQ,EAAE,gBAAgB,GAAG,SAAS,CAAC;CACxC,GAAG,MAAM,EAAE,CAwCX"}

package/dist/ddl/mysql.d.ts

@@ -0,0 +1,46 @@
+/**
+ * MySQL DDL renderer: migration steps → SQL statements.
+ *
+ * Every identifier is backtick-quoted through `mysqlDialect.quoteIdent` — the
+ * ONE quoting decision point. Pinned choices:
+ *
+ * - String → varchar(191): utf8mb4 × 4 bytes keeps indexed String columns
+ *   inside the 767-byte legacy InnoDB index-key limit (`@db.Text` opts out —
+ *   TEXT columns are never indexed by us; indexing one would need a prefix
+ *   length we do not emit).
+ * - autoincrement renders `AUTO_INCREMENT` (the column must be a key — the
+ *   PRIMARY KEY clause in the same CREATE TABLE satisfies that; ALTERing one
+ *   onto an existing column is refused, pg parity).
+ * - Enums are inline `ENUM('A', 'B')` column types; the standalone enum steps
+ *   (createEnum/dropEnum/addEnumValue) render NOTHING — value changes arrive
+ *   as alterColumn steps (value-based type keys) and render as MODIFY COLUMN
+ *   with the widened list.
+ * - alterColumn type/nullability → one `MODIFY COLUMN` with the full target
+ *   definition (mysql redefines the column wholesale); default-only changes
+ *   use `ALTER COLUMN … SET/DROP DEFAULT`.
+ * - No partial indexes on mysql → VIBE_UNSUPPORTED_CAPABILITY naming the
+ *   index. Index kinds other than btree are refused the same way.
+ * - `DROP INDEX … ON table` needs the table — the differ's dropIndex steps
+ *   carry it; a step without one is a VIBE_MIGRATION error.
+ * - `DROP TABLE` has no cascade (mysql parses `CASCADE` and ignores it), and
+ *   dropping a parent still referenced by another to-be-dropped table fails
+ *   with errno 3730 `ER_FK_CANNOT_DROP_PARENT` (observed live on 8.4). FK
+ *   drops on SURVIVING tables come from the differ's bucket order; drops of
+ *   whole dependent groups are topologically reordered children-first here
+ *   (the shared `orderDropsChildrenFirst`, same rule as sqlite).
+ */
+import type { SchemaIR } from "@vibeorm/schema";
+import type { MigrationStep } from "../types.ts";
+/**
+ * Render migration steps to mysql SQL. `to` (the target schema) is required
+ * whenever an enum column is rendered — the inline `ENUM(…)` type needs the
+ * enum's values, which live on the schema, not the step. `from` enables the
+ * topological drop order (children before referenced parents); without it,
+ * drops render in step order.
+ */
+export declare function renderMysqlSteps(params: {
+    steps: readonly MigrationStep[];
+    from?: SchemaIR;
+    to?: SchemaIR;
+}): string[];
+//# sourceMappingURL=mysql.d.ts.map

package/dist/ddl/mysql.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"mysql.d.ts","sourceRoot":"","sources":["../../src/ddl/mysql.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AAGH,OAAO,KAAK,EAAmB,QAAQ,EAAE,MAAM,iBAAiB,CAAC;AAMjE,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAIjD;;;;;;GAMG;AACH,wBAAgB,gBAAgB,CAAC,MAAM,EAAE;IACvC,KAAK,EAAE,SAAS,aAAa,EAAE,CAAC;IAChC,IAAI,CAAC,EAAE,QAAQ,CAAC;IAChB,EAAE,CAAC,EAAE,QAAQ,CAAC;CACf,GAAG,MAAM,EAAE,CAwBX"}

package/dist/ddl/postgres.d.ts

@@ -0,0 +1,24 @@
+/**
+ * Postgres DDL renderer: migration steps → SQL statements.
+ *
+ * Every identifier is quoted through `postgresDialect.quoteIdent` — the ONE
+ * quoting decision point (@vibeorm/sql). Choices, each pinned by a renderer
+ * test:
+ *
+ * - autoincrement renders as `GENERATED BY DEFAULT AS IDENTITY` (SQL-standard,
+ *   no sequence-name coupling; postgres ≥10 and pglite both support it) — not
+ *   SERIAL. The introspector maps identity columns back to autoincrement.
+ * - `DROP TABLE ... CASCADE`: inbound FK constraints drop with the table.
+ * - scalar→array type changes carry the LEARNINGS `USING CASE WHEN col IS NULL
+ *   THEN NULL ELSE ARRAY[col] END` repair clause (postgres cannot implicit-cast).
+ * - `ALTER TYPE ... ADD VALUE IF NOT EXISTS` appends at the end of the enum
+ *   (no BEFORE/AFTER positioning); fine inside a transaction on postgres ≥12.
+ * - Unsupported columns render their `nativeType` verbatim and migrate like
+ *   any other column.
+ */
+import type { MigrationStep } from "../types.ts";
+/** Render migration steps to postgres SQL (one string per statement, in order). */
+export declare function renderPostgresSteps(params: {
+    steps: readonly MigrationStep[];
+}): string[];
+//# sourceMappingURL=postgres.d.ts.map

package/dist/ddl/postgres.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"postgres.d.ts","sourceRoot":"","sources":["../../src/ddl/postgres.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAYH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAIjD,mFAAmF;AACnF,wBAAgB,mBAAmB,CAAC,MAAM,EAAE;IAAE,KAAK,EAAE,SAAS,aAAa,EAAE,CAAA;CAAE,GAAG,MAAM,EAAE,CAEzF"}

package/dist/ddl/render.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Dialect dispatcher for DDL rendering — the ONE public entry point. Routes to
+ * the per-dialect renderers (ddl/postgres.ts, ddl/sqlite.ts, ddl/mysql.ts) so
+ * every SQL-text decision stays in exactly one dialect module.
+ */
+import type { Dialect, SchemaIR } from "@vibeorm/schema";
+import type { MigrationStep } from "../types.ts";
+/**
+ * Render migration steps to SQL statements (one string per statement, in
+ * order) for a dialect.
+ *
+ * `from`/`to` — the schemas the steps were diffed from — are OPTIONAL for
+ * postgres (ignored) but needed by sqlite whenever a step compiles to the
+ * table-rebuild recipe (the target table shape lives on the schema, not the
+ * step) and by sqlite/mysql for enum columns (CHECK / inline ENUM values).
+ * `generateMigration` and `push` always pass them; direct callers rendering
+ * rebuild-free, enum-free steps may omit them.
+ */
+export declare function renderSteps(params: {
+    steps: readonly MigrationStep[];
+    dialect: Dialect;
+    from?: SchemaIR;
+    to?: SchemaIR;
+}): string[];
+//# sourceMappingURL=render.d.ts.map

package/dist/ddl/render.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"render.d.ts","sourceRoot":"","sources":["../../src/ddl/render.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,OAAO,KAAK,EAAE,OAAO,EAAE,QAAQ,EAAE,MAAM,iBAAiB,CAAC;AAIzD,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAEjD;;;;;;;;;;GAUG;AACH,wBAAgB,WAAW,CAAC,MAAM,EAAE;IAClC,KAAK,EAAE,SAAS,aAAa,EAAE,CAAC;IAChC,OAAO,EAAE,OAAO,CAAC;IACjB,IAAI,CAAC,EAAE,QAAQ,CAAC;IAChB,EAAE,CAAC,EAAE,QAAQ,CAAC;CACf,GAAG,MAAM,EAAE,CAkBX"}

package/dist/ddl/sqlite.d.ts

@@ -0,0 +1,62 @@
+/**
+ * SQLite DDL renderer: migration steps → SQL statements, including THE TABLE
+ * REBUILD — sqlite has no ALTER COLUMN, cannot add/drop constraints, and its
+ * DROP COLUMN is heavily restricted, so any such step compiles to the
+ * documented 12-step recipe (https://sqlite.org/lang_altertable.html §7),
+ * emitted as an ordered, self-contained statement block:
+ *
+ *   PRAGMA foreign_keys=OFF;
+ *   BEGIN;
+ *   CREATE TABLE "T_new" (…target shape: columns, PK, FKs, enum CHECKs…);
+ *   INSERT INTO "T_new" (common cols) SELECT common cols FROM "T";
+ *   DROP TABLE "T";
+ *   ALTER TABLE "T_new" RENAME TO "T";
+ *   CREATE …INDEX… (every index of the target table);
+ *   PRAGMA foreign_key_check;
+ *   COMMIT;
+ *   PRAGMA foreign_keys=ON;
+ *
+ * Because the block manages its own transaction (PRAGMA foreign_keys is a
+ * no-op inside one), callers must NOT wrap scripts containing it — push and
+ * the runner detect this via `usesSelfManagedTransactions` (execute.ts).
+ * Rebuild blocks are emitted AFTER all other statements so a rebuilt table's
+ * new FKs can reference tables created earlier in the same script.
+ *
+ * Cheap paths are preferred wherever sqlite's plain ALTER suffices:
+ * `ADD COLUMN` (unless the column is required without a literal default, or
+ * defaults to CURRENT_TIMESTAMP / an expression — both forbidden in ADD
+ * COLUMN) and `DROP COLUMN` (unless the column is in the PK, any index or
+ * partial-index predicate, an FK on either side, or carries an enum CHECK).
+ *
+ * Column-value transfer on rebuild: dropped columns are omitted, added
+ * columns take their default (or NULL), type-changed columns are a PLAIN COPY
+ * — sqlite's flexible typing keeps the stored values as-is, so e.g. non-numeric
+ * TEXT survives verbatim inside an INTEGER column (documented lossy-ness:
+ * nothing is coerced, nothing is validated beyond the new CHECK constraints).
+ *
+ * Other pinned choices:
+ * - autoincrement renders `INTEGER PRIMARY KEY AUTOINCREMENT` (monotonic ids,
+ *   Prisma parity) — plain `INTEGER PRIMARY KEY` would reuse rowids after
+ *   deletes. The `PRIMARY KEY AUTOINCREMENT` text is also the introspection
+ *   marker. Costs the `sqlite_sequence` bookkeeping table (skipped on pull).
+ * - Composite / non-autoincrement PKs render as an unnamed table-level
+ *   `PRIMARY KEY (…)` (sqlite keeps constraint names only as noise).
+ * - Enums render TEXT + a NAMED column-level CHECK (see sqlite-types.ts) —
+ *   the name (`<table>_<column>_enum_<Enum>`) is how pull recovers the enum.
+ * - `DROP TABLE` has no CASCADE on sqlite; table drops are topologically
+ *   ordered (referencing tables first) using the `from` schema.
+ * - Index kinds other than btree/unique throw VIBE_UNSUPPORTED_CAPABILITY.
+ */
+import type { SchemaIR } from "@vibeorm/schema";
+import type { MigrationStep } from "../types.ts";
+/**
+ * Render migration steps to sqlite SQL. `from`/`to` (the schemas that produced
+ * the steps) are required whenever a step triggers a table rebuild or renders
+ * an enum column — `generateMigration` and `push` always pass them.
+ */
+export declare function renderSqliteSteps(params: {
+    steps: readonly MigrationStep[];
+    from?: SchemaIR;
+    to?: SchemaIR;
+}): string[];
+//# sourceMappingURL=sqlite.d.ts.map

package/dist/ddl/sqlite.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"sqlite.d.ts","sourceRoot":"","sources":["../../src/ddl/sqlite.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AAGH,OAAO,KAAK,EAAmB,QAAQ,EAAE,MAAM,iBAAiB,CAAC;AAajE,OAAO,KAAK,EAAe,aAAa,EAAE,MAAM,aAAa,CAAC;AAI9D;;;;GAIG;AACH,wBAAgB,iBAAiB,CAAC,MAAM,EAAE;IACxC,KAAK,EAAE,SAAS,aAAa,EAAE,CAAC;IAChC,IAAI,CAAC,EAAE,QAAQ,CAAC;IAChB,EAAE,CAAC,EAAE,QAAQ,CAAC;CACf,GAAG,MAAM,EAAE,CAkLX"}

package/dist/differ.d.ts

@@ -0,0 +1,33 @@
+/**
+ * IR-vs-IR schema differ → dialect-neutral migration steps.
+ *
+ * The contract that matters most: `diffSchemas({ from: introspect(push(X)),
+ * to: X })` is EMPTY — both sides normalize through normalize.ts before
+ * comparison, so representation differences (implicit list sides vs explicit
+ * M2M fields, `@unique` vs `@@unique`, app-level defaults, cascade-action
+ * defaults) never produce phantom steps and `db push` twice is a no-op.
+ *
+ * No rename detection (v1 parity): a renamed table/column diffs as drop +
+ * create. Removing a value from a surviving enum throws
+ * VIBE_UNSUPPORTED_CAPABILITY — postgres cannot drop enum values without a
+ * manual type rebuild, and silence would be dialect dishonesty.
+ */
+import type { Dialect, SchemaIR } from "@vibeorm/schema";
+import type { MigrationStep } from "./types.ts";
+/**
+ * Diff two Schema IRs into an ordered list of dialect-neutral migration steps
+ * that transform the `from` database shape into the `to` shape.
+ *
+ * `dialect` (default postgres) selects the comparison rules: sqlite/mysql
+ * compare columns by physical type (see normalize.ts), refuse scalar-list
+ * columns up front (no array types — VIBE_UNSUPPORTED_CAPABILITY naming the
+ * model.field), skip standalone enum steps (their enums are inline: TEXT +
+ * CHECK on sqlite, `ENUM(…)` on mysql — value changes flow through
+ * `alterColumn`), and refuse enum-value REMOVAL at the column level.
+ */
+export declare function diffSchemas(params: {
+    from: SchemaIR;
+    to: SchemaIR;
+    dialect?: Dialect;
+}): MigrationStep[];
+//# sourceMappingURL=differ.d.ts.map

package/dist/differ.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"differ.d.ts","sourceRoot":"","sources":["../src/differ.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAGH,OAAO,KAAK,EAAE,OAAO,EAAU,QAAQ,EAAE,MAAM,iBAAiB,CAAC;AAKjE,OAAO,KAAK,EAAqB,aAAa,EAAE,MAAM,YAAY,CAAC;AAkCnE;;;;;;;;;;GAUG;AACH,wBAAgB,WAAW,CAAC,MAAM,EAAE;IAClC,IAAI,EAAE,QAAQ,CAAC;IACf,EAAE,EAAE,QAAQ,CAAC;IACb,OAAO,CAAC,EAAE,OAAO,CAAC;CACnB,GAAG,aAAa,EAAE,CAsDlB"}

package/dist/down.d.ts

@@ -0,0 +1,55 @@
+/**
+ * Down-migration generation: the REVERSE diff of an up migration, with v1's
+ * two rollback rules baked in (LEARNINGS / issue #15):
+ *
+ * 1. RE-ADDED COLUMNS COME BACK NULLABLE. The reverse of `dropColumn` is
+ *    `addColumn`, but the dropped column's data is gone — re-adding it
+ *    NOT NULL would fail on any populated table. Every `addColumn` step in a
+ *    down migration is therefore forced optional (its default, when present,
+ *    is kept). Whole-table re-creates (`createTable`) keep their NOT NULLs:
+ *    the re-created table is empty.
+ * 2. IRREVERSIBLE UP-STEPS ARE SKIPPED, NOT THROWN. An up migration that
+ *    added an enum value has no reverse — postgres cannot drop enum values,
+ *    and sqlite/mysql refuse narrowing an inline enum whose rows may hold the
+ *    value. The rollback target keeps those values and the skip is reported
+ *    in `skipped`, so "undo the last migration" still works (v1's
+ *    `isReversible: false` behavior).
+ *
+ * Extension artifacts: object artifacts the up migration created (columns,
+ * indexes, shadow tables, triggers) are dropped by the down migration via
+ * their own `drop` SQL. `CREATE EXTENSION`-class artifacts are never dropped
+ * — other database objects may depend on the extension — and are reported in
+ * `skipped` instead.
+ */
+import type { Dialect, SchemaIR, VibeExtension } from "@vibeorm/schema";
+/** A generated down migration: reverse SQL plus what could NOT be reversed. */
+export type DownMigrationFile = {
+    readonly name: string;
+    /** One SQL string per statement, in execution order. */
+    readonly sql: readonly string[];
+    /** True when any reverse step can lose data (e.g. dropping an up-added column). */
+    readonly destructive: boolean;
+    /**
+     * Human descriptions of up-changes this down migration cannot reverse
+     * (added enum values, installed postgres extensions). Empty = full reverse.
+     */
+    readonly skipped: readonly string[];
+};
+/**
+ * Generate the DOWN migration for an up migration described by the same
+ * `from`/`to` pair handed to `generateMigration`: `from` is the current
+ * database shape, `to` the schema the up migration moves to. The down
+ * migration transforms `to` back into `from` (modulo the skipped
+ * irreversibles), so callers write it alongside the up file and apply it
+ * newest-first to roll back.
+ */
+export declare function generateDownMigration(params: {
+    from: SchemaIR;
+    to: SchemaIR;
+    name: string;
+    /** Rendering dialect; postgres if omitted. */
+    dialect?: Dialect;
+    /** Configured extension instances — their up-created artifacts are dropped. */
+    extensions?: readonly VibeExtension[];
+}): DownMigrationFile;
+//# sourceMappingURL=down.d.ts.map

package/dist/down.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"down.d.ts","sourceRoot":"","sources":["../src/down.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH,OAAO,KAAK,EAAE,OAAO,EAAU,QAAQ,EAAE,aAAa,EAAE,MAAM,iBAAiB,CAAC;AAYhF,+EAA+E;AAC/E,MAAM,MAAM,iBAAiB,GAAG;IAC9B,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,wDAAwD;IACxD,QAAQ,CAAC,GAAG,EAAE,SAAS,MAAM,EAAE,CAAC;IAChC,mFAAmF;IACnF,QAAQ,CAAC,WAAW,EAAE,OAAO,CAAC;IAC9B;;;OAGG;IACH,QAAQ,CAAC,OAAO,EAAE,SAAS,MAAM,EAAE,CAAC;CACrC,CAAC;AAyDF;;;;;;;GAOG;AACH,wBAAgB,qBAAqB,CAAC,MAAM,EAAE;IAC5C,IAAI,EAAE,QAAQ,CAAC;IACf,EAAE,EAAE,QAAQ,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,8CAA8C;IAC9C,OAAO,CAAC,EAAE,OAAO,CAAC;IAClB,+EAA+E;IAC/E,UAAU,CAAC,EAAE,SAAS,aAAa,EAAE,CAAC;CACvC,GAAG,iBAAiB,CAuDpB"}

package/dist/enum-values.d.ts

@@ -0,0 +1,19 @@
+/**
+ * Enum-value resolution shared by the sqlite/mysql type mappers.
+ *
+ * On dialects without named enum types (sqlite: TEXT + CHECK, mysql: inline
+ * `ENUM(...)`) the enum's NAME does not survive in the database — only its
+ * VALUES do. Column comparison keys and DDL rendering therefore resolve a
+ * field's enum reference to its value list; the name is presentation only.
+ */
+import type { EnumIR } from "@vibeorm/schema";
+/**
+ * Resolve an enum name to its values. The map is keyed by db name
+ * (`dbName ?? name`, the normalize.ts convention); a schema-side reference by
+ * IR name falls back to a scan so both key styles resolve.
+ */
+export declare function resolveEnumValues(params: {
+    name: string;
+    enums: ReadonlyMap<string, EnumIR>;
+}): readonly string[] | undefined;
+//# sourceMappingURL=enum-values.d.ts.map

package/dist/enum-values.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"enum-values.d.ts","sourceRoot":"","sources":["../src/enum-values.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,iBAAiB,CAAC;AAE9C;;;;GAIG;AACH,wBAAgB,iBAAiB,CAAC,MAAM,EAAE;IACxC,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,WAAW,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;CACpC,GAAG,SAAS,MAAM,EAAE,GAAG,SAAS,CAQhC"}

package/dist/execute.d.ts

@@ -0,0 +1,41 @@
+/**
+ * Statement-execution helpers shared by push and the migration runner.
+ *
+ * Two sqlite realities live here:
+ *
+ * - SELF-MANAGED SCRIPTS: the table-rebuild recipe (ddl/sqlite.ts) carries its
+ *   own `PRAGMA foreign_keys=OFF; BEGIN; … COMMIT; PRAGMA foreign_keys=ON;`
+ *   sequence, because `PRAGMA foreign_keys` is a no-op inside a transaction.
+ *   Callers must NOT wrap such scripts in an outer BEGIN/COMMIT —
+ *   `usesSelfManagedTransactions` detects them. Plain statements in a
+ *   self-managed script auto-commit individually (documented sqlite
+ *   limitation: a mixed script is not atomic as a whole; each rebuild block
+ *   is).
+ * - `PRAGMA foreign_key_check` RETURNS VIOLATION ROWS instead of failing —
+ *   `executeStatement` runs it row-returning (`values: []`, the adapter-sqlite
+ *   contract for reads) and throws VIBE_MIGRATION when any come back.
+ */
+import type { Dialect } from "@vibeorm/schema";
+import type { SqlExecutor } from "./types.ts";
+/** True when the script manages its own transactions (sqlite rebuilds). */
+export declare function usesSelfManagedTransactions(params: {
+    sql: readonly string[];
+}): boolean;
+/**
+ * Execute one migration statement. On sqlite, `PRAGMA foreign_key_check` is
+ * executed row-returning and its violations become a VIBE_MIGRATION error.
+ */
+export declare function executeStatement(params: {
+    executor: SqlExecutor;
+    statement: string;
+    dialect: Dialect;
+}): Promise<void>;
+/**
+ * Best-effort cleanup after a failed self-managed sqlite script: roll back a
+ * possibly-open rebuild transaction and restore FK enforcement. Never throws
+ * — the original failure matters more.
+ */
+export declare function cleanupSelfManagedFailure(params: {
+    executor: SqlExecutor;
+}): Promise<void>;
+//# sourceMappingURL=execute.d.ts.map

package/dist/execute.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"execute.d.ts","sourceRoot":"","sources":["../src/execute.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAGH,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,iBAAiB,CAAC;AAC/C,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,YAAY,CAAC;AAO9C,2EAA2E;AAC3E,wBAAgB,2BAA2B,CAAC,MAAM,EAAE;IAAE,GAAG,EAAE,SAAS,MAAM,EAAE,CAAA;CAAE,GAAG,OAAO,CAEvF;AAED;;;GAGG;AACH,wBAAsB,gBAAgB,CAAC,MAAM,EAAE;IAC7C,QAAQ,EAAE,WAAW,CAAC;IACtB,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,OAAO,CAAC;CAClB,GAAG,OAAO,CAAC,IAAI,CAAC,CAkBhB;AAED;;;;GAIG;AACH,wBAAsB,yBAAyB,CAAC,MAAM,EAAE;IAAE,QAAQ,EAAE,WAAW,CAAA;CAAE,GAAG,OAAO,CAAC,IAAI,CAAC,CAWhG"}

package/dist/extensions.d.ts

@@ -0,0 +1,74 @@
+/**
+ * Extension artifacts in the migrate pipeline (extensions.md §3 migrate plane).
+ *
+ * Extensions own database objects the core differ does not model: CREATE
+ * EXTENSION, generated tsvector columns, FTS5 shadow tables + triggers,
+ * specialty indexes (gin_trgm_ops, hnsw, bm25, FULLTEXT). The contract:
+ *
+ *   1. `collectExtensionArtifacts` asks each configured extension for its
+ *      artifacts (dialect-correct, idempotent SQL + a structured owner).
+ *   2. `stripExtensionArtifacts` removes owned objects from the INTROSPECTED
+ *      IR before diffing, so the core differ never schedules their drop —
+ *      the introspector-representation-is-the-contract rule (LEARNINGS).
+ *   3. `planMissingArtifacts` decides which artifacts must be created, by
+ *      checking the introspected IR for their owners (columns, indexes,
+ *      tables by name); non-introspectable owners (postgres extensions,
+ *      triggers) rely on their idempotent IF NOT EXISTS forms and always run.
+ *
+ * Removing a declaration does NOT auto-drop its artifacts (mirrors the v1
+ * phantom-join-table precedent) — `drop` SQL is carried for tooling, not
+ * scheduled by push.
+ */
+import type { Dialect, ExtensionArtifact, SchemaIR, VibeExtension } from "@vibeorm/schema";
+/** Artifacts of every configured extension for this schema, in order. */
+export type CollectedArtifacts = {
+    /** CREATE EXTENSION-class artifacts — run BEFORE the core diff SQL. */
+    readonly setup: readonly ExtensionArtifact[];
+    /** Object artifacts (columns, indexes, shadow tables, triggers) — run AFTER. */
+    readonly objects: readonly ExtensionArtifact[];
+};
+export declare function collectExtensionArtifacts(params: {
+    schema: SchemaIR;
+    dialect: Dialect;
+    extensions: readonly VibeExtension[];
+}): CollectedArtifacts;
+/**
+ * Remove extension-owned objects from an INTROSPECTED SchemaIR so the core
+ * differ never sees them (they are neither dropped nor re-created by it).
+ */
+export declare function stripExtensionArtifacts(params: {
+    schema: SchemaIR;
+    artifacts: readonly ExtensionArtifact[];
+}): SchemaIR;
+/** Owner presence the IR cannot answer, probed live by push (both optional). */
+export type InstalledExtensionState = {
+    /** `SELECT extname FROM pg_extension` — postgres only. */
+    readonly pgExtensions?: ReadonlySet<string>;
+    /** `sqlite_master WHERE type='trigger'` names — sqlite only. */
+    readonly triggers?: ReadonlySet<string>;
+};
+/**
+ * The artifacts whose owner is missing from the introspected IR (must be
+ * created). Owners the IR cannot see — postgres extensions and triggers —
+ * consult the live-probed `installed` state when given, else always plan;
+ * their `create` SQL is idempotent (IF NOT EXISTS) so replays converge.
+ */
+export declare function planMissingArtifacts(params: {
+    introspected: SchemaIR;
+    artifacts: readonly ExtensionArtifact[];
+    installed?: InstalledExtensionState;
+}): ExtensionArtifact[];
+/** Probe live owner state the IR cannot carry (used by push before planning). */
+export declare function probeInstalledExtensionState(params: {
+    executor: (execParams: {
+        text: string;
+        values?: unknown[];
+    }) => Promise<Record<string, unknown>[]>;
+    dialect: Dialect;
+    artifacts: readonly ExtensionArtifact[];
+}): Promise<InstalledExtensionState>;
+/** Flatten artifacts to their create statements, in order. */
+export declare function artifactCreateSql(params: {
+    artifacts: readonly ExtensionArtifact[];
+}): string[];
+//# sourceMappingURL=extensions.d.ts.map

package/dist/extensions.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"extensions.d.ts","sourceRoot":"","sources":["../src/extensions.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AAGH,OAAO,KAAK,EACV,OAAO,EACP,iBAAiB,EAEjB,QAAQ,EACR,aAAa,EACd,MAAM,iBAAiB,CAAC;AAIzB,yEAAyE;AACzE,MAAM,MAAM,kBAAkB,GAAG;IAC/B,uEAAuE;IACvE,QAAQ,CAAC,KAAK,EAAE,SAAS,iBAAiB,EAAE,CAAC;IAC7C,gFAAgF;IAChF,QAAQ,CAAC,OAAO,EAAE,SAAS,iBAAiB,EAAE,CAAC;CAChD,CAAC;AAEF,wBAAgB,yBAAyB,CAAC,MAAM,EAAE;IAChD,MAAM,EAAE,QAAQ,CAAC;IACjB,OAAO,EAAE,OAAO,CAAC;IACjB,UAAU,EAAE,SAAS,aAAa,EAAE,CAAC;CACtC,GAAG,kBAAkB,CAwBrB;AAkBD;;;GAGG;AACH,wBAAgB,uBAAuB,CAAC,MAAM,EAAE;IAC9C,MAAM,EAAE,QAAQ,CAAC;IACjB,SAAS,EAAE,SAAS,iBAAiB,EAAE,CAAC;CACzC,GAAG,QAAQ,CAyCX;AAID,gFAAgF;AAChF,MAAM,MAAM,uBAAuB,GAAG;IACpC,0DAA0D;IAC1D,QAAQ,CAAC,YAAY,CAAC,EAAE,WAAW,CAAC,MAAM,CAAC,CAAC;IAC5C,gEAAgE;IAChE,QAAQ,CAAC,QAAQ,CAAC,EAAE,WAAW,CAAC,MAAM,CAAC,CAAC;CACzC,CAAC;AAEF;;;;;GAKG;AACH,wBAAgB,oBAAoB,CAAC,MAAM,EAAE;IAC3C,YAAY,EAAE,QAAQ,CAAC;IACvB,SAAS,EAAE,SAAS,iBAAiB,EAAE,CAAC;IACxC,SAAS,CAAC,EAAE,uBAAuB,CAAC;CACrC,GAAG,iBAAiB,EAAE,CA8BtB;AAED,iFAAiF;AACjF,wBAAsB,4BAA4B,CAAC,MAAM,EAAE;IACzD,QAAQ,EAAE,CAAC,UAAU,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,MAAM,CAAC,EAAE,OAAO,EAAE,CAAA;KAAE,KAAK,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAAE,CAAC,CAAC;IACnG,OAAO,EAAE,OAAO,CAAC;IACjB,SAAS,EAAE,SAAS,iBAAiB,EAAE,CAAC;CACzC,GAAG,OAAO,CAAC,uBAAuB,CAAC,CAiBnC;AAED,8DAA8D;AAC9D,wBAAgB,iBAAiB,CAAC,MAAM,EAAE;IACxC,SAAS,EAAE,SAAS,iBAAiB,EAAE,CAAC;CACzC,GAAG,MAAM,EAAE,CAEX"}

package/dist/index.d.ts

@@ -0,0 +1,26 @@
+/**
+ * @vibeorm/migrate — schema diffing, per-dialect DDL rendering, migration
+ * running, push/pull and database introspection for VibeORM v2.
+ *
+ * All three dialects are live: postgres/pglite, sqlite (table-rebuild recipe
+ * for the ALTERs sqlite cannot express) and mysql (non-transactional runner
+ * with per-statement resume). `renderSteps` / `push` / `pull` /
+ * `generateMigration` / `applyMigrations` route per dialect; the per-dialect
+ * modules live under src/ddl/ and src/introspect/.
+ */
+export { describeStep } from "./types.ts";
+export type { AlterColumnAspect, AppliedResult, IndexColumn, JoinTableEnd, MigrationFile, MigrationStatus, MigrationStep, PushResult, SqlExecutor, } from "./types.ts";
+export { diffSchemas } from "./differ.ts";
+export { detectImplicitM2MPairs } from "./relations.ts";
+export type { ImplicitM2MPair } from "./relations.ts";
+export { renderSteps } from "./ddl/render.ts";
+export { introspectPostgres } from "./introspect/postgres.ts";
+export { introspectSqlite } from "./introspect/sqlite.ts";
+export { introspectMysql } from "./introspect/mysql.ts";
+export { MIGRATIONS_TABLE_NAME, applyMigrations, ensureMigrationsTable, generateMigration, migrationChecksum, migrationStatus, resolveMigration, rollbackMigration, } from "./runner.ts";
+export { generateDownMigration } from "./down.ts";
+export type { DownMigrationFile } from "./down.ts";
+export { pull, push } from "./push.ts";
+export { artifactCreateSql, collectExtensionArtifacts, planMissingArtifacts, probeInstalledExtensionState, stripExtensionArtifacts, } from "./extensions.ts";
+export type { CollectedArtifacts, InstalledExtensionState } from "./extensions.ts";
+//# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAIH,OAAO,EAAE,YAAY,EAAE,MAAM,YAAY,CAAC;AAC1C,YAAY,EACV,iBAAiB,EACjB,aAAa,EACb,WAAW,EACX,YAAY,EACZ,aAAa,EACb,eAAe,EACf,aAAa,EACb,UAAU,EACV,WAAW,GACZ,MAAM,YAAY,CAAC;AAIpB,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AAC1C,OAAO,EAAE,sBAAsB,EAAE,MAAM,gBAAgB,CAAC;AACxD,YAAY,EAAE,eAAe,EAAE,MAAM,gBAAgB,CAAC;AAItD,OAAO,EAAE,WAAW,EAAE,MAAM,iBAAiB,CAAC;AAI9C,OAAO,EAAE,kBAAkB,EAAE,MAAM,0BAA0B,CAAC;AAC9D,OAAO,EAAE,gBAAgB,EAAE,MAAM,wBAAwB,CAAC;AAC1D,OAAO,EAAE,eAAe,EAAE,MAAM,uBAAuB,CAAC;AAIxD,OAAO,EACL,qBAAqB,EACrB,eAAe,EACf,qBAAqB,EACrB,iBAAiB,EACjB,iBAAiB,EACjB,eAAe,EACf,gBAAgB,EAChB,iBAAiB,GAClB,MAAM,aAAa,CAAC;AAIrB,OAAO,EAAE,qBAAqB,EAAE,MAAM,WAAW,CAAC;AAClD,YAAY,EAAE,iBAAiB,EAAE,MAAM,WAAW,CAAC;AAInD,OAAO,EAAE,IAAI,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AAIvC,OAAO,EACL,iBAAiB,EACjB,yBAAyB,EACzB,oBAAoB,EACpB,4BAA4B,EAC5B,uBAAuB,GACxB,MAAM,iBAAiB,CAAC;AACzB,YAAY,EAAE,kBAAkB,EAAE,uBAAuB,EAAE,MAAM,iBAAiB,CAAC"}