@pitlane/data-table-d1/migrations

Compiles data-table migrations into the flat .sql files Wrangler's D1 migration runner reads.

Node-only build tooling. Nothing here belongs in a Worker bundle, which is why it is a separate entry point from the driver.

Interfaces

GenerateD1MigrationsOptions

What generateD1Migrations needs to know.

Properties

from?

optional from?: string;

Directory holding the data-table migrations, one <id>_<name>/ directory per migration.

Default

"db/migrations"

to

to: string;

Where the generated .sql files land. Point this at the same directory as migrations_dir in your Wrangler config.

---

GeneratedD1Migration

One generated file.

Properties

file

file: string;

Path of the written file, relative to the working directory.

id

id: string;

Migration id, typically a YYYYMMDDHHmmss timestamp.

name

name: string;

Migration slug.

Functions

generateD1Migrations()

function generateD1Migrations(options): Promise<GeneratedD1Migration[]>;

Writes one <id>_<name>.sql per migration into options.to, then deletes generated files with no migration behind them, so the output directory is a pure function of the input one.

The SQL is copied verbatim. Splitting it into statements is the job of whatever executes the file, and a splitter naive enough to write here would corrupt any migration containing a semicolon inside a string literal or a begin ... end trigger body.

Parameters

options

GenerateD1MigrationsOptions

Where to read migrations from, and where to write SQL to.

Returns

Promise<GeneratedD1Migration[]>

The generated files, ordered by migration id.

Throws

If options.from holds no migrations, or one of them has an empty up. Both mean the output directory is about to be wrong, and a migration runner is the worst place to discover that.

Example

import { generateD1Migrations } from "@pitlane/data-table-d1/migrations";

await generateD1Migrations({ to: "db/d1-migrations" });