@devdogsuga/devtools 0.1.26 → 0.1.28

package/dist/db/local-env.d.ts

@@ -1,65 +0,0 @@
-/**
- * The environment `db introspect` hands to the `drizzle-kit` child process
- * it spawns.
- *
- * ## How this relates to `db/connection.ts`
- *
- * `db/connection.ts` resolves the session's one database CONNECTION (its
- * `DB_URL`, with sanity guards) for commands that open one themselves. This
- * is the other need: a whole ENVIRONMENT to hand a child process. Both read
- * the same source — whatever THIS PROCESS already entered — `launch.ts`
- * runs before
- * `cli.ts`'s command dispatch even imports, and enters a tier (development,
- * by default) into `process.env` via `@devdogsuga/env/session`'s
- * `enterEnvironment`, applying `selectEnvFiles`'s overlay-plus-liveness-probe
- * logic (`.env.generated`, the running local stack's connection block,
- * ahead of `.env` — see `load.ts`'s probe table) along the way.
- *
- * These two commands used to bypass all of that: each parsed `.env` directly
- * with raw `dotenv`, and merged it OVER `process.env`
- * (`{...process.env, ...tierEnv}`). Two bugs followed from that shortcut:
- *
- *   a. `.env.generated` — where the running local stack's `DB_URL` actually
- *      lives — was never read, so with the stack up these commands reported
- *      "DB_URL is not set in .env. Run `supabase start` first" (wrong
- *      command AND wrong file) or silently connected to a stale/hosted URL,
- *      while every other command in this CLI, going through `selectEnvFiles`,
- *      worked fine.
- *   b. The precedence was inverted: a raw `.env` parse merged OVER
- *      `process.env` clobbers whatever tier this process actually entered —
- *      backwards from the documented expectation (now `db/connection.ts`'s)
- *      that a command reads the tier the process is already running
- *      under rather than reimposing development on top of it.
- *
- * `resolveLocalToolingEnv` fixes both by returning `process.env` itself
- * (fresh values, `.env.generated` included, whatever tier was entered)
- * instead of re-deriving anything. The only case it still loads a tier
- * itself is a caller that reaches these commands WITHOUT going through
- * `launch.ts` first — `process.env.DEPLOY_ENV` unset is the tell, since
- * `enterEnvironment` always sets it, even for `development` — and even then
- * it falls back to `loadEnvironment("development")`, never a raw dotenv
- * parse, so the overlay-plus-probe logic still applies.
- */
-import type { LoadedEnvironment } from "@devdogsuga/env/load";
-export interface ResolveLocalToolingEnvOptions {
-    /** Injectable for tests; defaults to `process.env`. */
-    processEnv?: NodeJS.ProcessEnv;
-    /** Injectable for tests; defaults to the real `loadEnvironment`. */
-    loadEnvironment?: (deployEnv?: string, options?: {
-        override?: boolean;
-    }) => Promise<LoadedEnvironment>;
-}
-/**
- * Returns the environment a local-tooling child process (`drizzle-kit`,
- * spawned by `db introspect`) should inherit.
- *
- * Normal path (the process went through `launch.ts`, as `pnpm devtools`
- * always does): returns `process.env` unchanged — it already carries
- * whatever tier was entered, `.env.generated` overlay included.
- *
- * Fallback path (no tier was ever entered — a direct import, e.g. from a
- * test, or a future caller that skips `launch.ts`): loads development
- * through the shared `loadEnvironment`, which applies the same overlay and
- * liveness probe `selectEnvFiles` always has, then returns that snapshot.
- */
-export declare function resolveLocalToolingEnv(opts?: ResolveLocalToolingEnvOptions): Promise<NodeJS.ProcessEnv>;

package/dist/db/local-env.js

@@ -1,23 +0,0 @@
-import { loadEnvLoad } from "../repo/peers.js";
-/**
- * Returns the environment a local-tooling child process (`drizzle-kit`,
- * spawned by `db introspect`) should inherit.
- *
- * Normal path (the process went through `launch.ts`, as `pnpm devtools`
- * always does): returns `process.env` unchanged — it already carries
- * whatever tier was entered, `.env.generated` overlay included.
- *
- * Fallback path (no tier was ever entered — a direct import, e.g. from a
- * test, or a future caller that skips `launch.ts`): loads development
- * through the shared `loadEnvironment`, which applies the same overlay and
- * liveness probe `selectEnvFiles` always has, then returns that snapshot.
- */
-export async function resolveLocalToolingEnv(opts = {}) {
-    const processEnv = opts.processEnv ?? process.env;
-    if (processEnv.DEPLOY_ENV !== undefined && processEnv.DEPLOY_ENV !== "") {
-        return processEnv;
-    }
-    const load = opts.loadEnvironment ?? (await loadEnvLoad()).loadEnvironment;
-    const loaded = await load("development");
-    return loaded.env;
-}

package/dist/db/new-migration.d.ts

@@ -1,8 +0,0 @@
-/** App slug -> Postgres schema name. Schedule Builder and Study Group
- * Finder use underscores; their slugs use hyphens. */
-export declare const APP_SCHEMAS: Record<string, string>;
-/** Builds the `supabase migration new` name argument — `<schema>_<desc>` —
- * given an app slug and a free-text description. Pure, so the naming rule
- * is testable without spawning the CLI. */
-export declare function migrationName(appSlug: string, description: string): string | null;
-export declare function runNewMigration(appArg: string | undefined, descriptionArg: string | undefined): Promise<number>;

package/dist/db/new-migration.js

@@ -1,69 +0,0 @@
-/**
- * `db migration new --app <slug> <description>`
- *
- * One flat `supabase/migrations/` directory, shared by every app, so the
- * filename is the only thing that says whose schema a migration belongs to.
- * Contract: `<timestamp>_<schema>_<description>.sql`, where `schema` is
- * `platform`, `schedule_builder`, or `study_group_finder` — never the
- * app slug verbatim (schedule-builder's schema is `schedule_builder`, with
- * an underscore, because it is a Postgres identifier).
- *
- * The supabase CLI already produces `<timestamp>_<name>.sql` from `migration
- * new <name>` — its own clock, not ours, which is the part CI's
- * newer-than-main check actually cares about — so this only has to build
- * `name` as `<schema>_<description>` and hand it off unchanged.
- */
-import { select, text } from "@clack/prompts";
-import { unwrap } from "../ui.js";
-import { supabase } from "./run.js";
-/** App slug -> Postgres schema name. Schedule Builder and Study Group
- * Finder use underscores; their slugs use hyphens. */
-export const APP_SCHEMAS = {
-    platform: "platform",
-    "schedule-builder": "schedule_builder",
-    "study-group-finder": "study_group_finder",
-};
-/** Builds the `supabase migration new` name argument — `<schema>_<desc>` —
- * given an app slug and a free-text description. Pure, so the naming rule
- * is testable without spawning the CLI. */
-export function migrationName(appSlug, description) {
-    const schema = APP_SCHEMAS[appSlug];
-    if (!schema)
-        return null;
-    const slug = description
-        .trim()
-        .toLowerCase()
-        .replace(/[^a-z0-9]+/g, "_")
-        .replace(/^_+|_+$/g, "");
-    if (!slug)
-        return null;
-    return `${schema}_${slug}`;
-}
-async function pickApp() {
-    return unwrap(await select({
-        message: "Whose schema is this migration for?",
-        options: Object.keys(APP_SCHEMAS).map((value) => ({
-            value,
-            label: value,
-        })),
-    }));
-}
-export async function runNewMigration(appArg, descriptionArg) {
-    const app = appArg ?? (await pickApp());
-    if (!APP_SCHEMAS[app]) {
-        process.stderr.write(`devtools db migration new: unknown app "${app}". Expected one of: ${Object.keys(APP_SCHEMAS).join(", ")}.\n`);
-        return 1;
-    }
-    const description = descriptionArg ??
-        unwrap(await text({
-            message: "Short description (used as the migration's filename)",
-            placeholder: "add_widgets_table",
-            validate: (v) => (v?.trim() ? undefined : "Required"),
-        }));
-    const name = migrationName(app, description);
-    if (!name) {
-        process.stderr.write("devtools db migration new: the description left nothing usable in the filename.\n");
-        return 1;
-    }
-    return supabase("migration", "new", name);
-}

package/dist/db/pooler.d.ts

@@ -1,23 +0,0 @@
-/**
- * Validates a hosted `DB_URL` against the one shape it must have: the
- * Session pooler string, not the direct connection and not the Transaction
- * pooler.
- *
- * Pure and synchronous on purpose — `setup.ts`'s hosted wizard calls this
- * before writing anything to `.env`, and `doctor.ts`'s environment checker
- * calls the same function against whatever is already there, so the two
- * never drift into disagreeing about what a good `DB_URL` looks like.
- *
- * See the writing guide's collapsed note on poolers (docs/_shared or
- * toolkit/guides) for the wording this explains to a contributor; this
- * module only classifies, it does not print.
- */
-export type DbUrlProblem = "invalid" | "direct-connection" | "transaction-pooler";
-export interface DbUrlValidation {
-    ok: boolean;
-    problem?: DbUrlProblem;
-    /** The FAQ anchor id for this problem, for a caller that wants to link. */
-    faqId?: "db-url-direct-connection" | "db-url-transaction-pooler";
-    message?: string;
-}
-export declare function validateSessionPoolerUrl(dbUrl: string): DbUrlValidation;

package/dist/db/pooler.js

@@ -1,55 +0,0 @@
-/**
- * Validates a hosted `DB_URL` against the one shape it must have: the
- * Session pooler string, not the direct connection and not the Transaction
- * pooler.
- *
- * Pure and synchronous on purpose — `setup.ts`'s hosted wizard calls this
- * before writing anything to `.env`, and `doctor.ts`'s environment checker
- * calls the same function against whatever is already there, so the two
- * never drift into disagreeing about what a good `DB_URL` looks like.
- *
- * See the writing guide's collapsed note on poolers (docs/_shared or
- * toolkit/guides) for the wording this explains to a contributor; this
- * module only classifies, it does not print.
- */
-/** `db.<ref>.supabase.co` — the direct connection host, IPv6-only on the
- * free tier. */
-const DIRECT_CONNECTION_HOST = /^db\.[a-z0-9]+\.supabase\.co$/i;
-/** The Transaction pooler's port. Session pooler is 5432, same as plain
- * Postgres. */
-const TRANSACTION_POOLER_PORT = "6543";
-export function validateSessionPoolerUrl(dbUrl) {
-    let url;
-    try {
-        url = new URL(dbUrl);
-    }
-    catch {
-        return {
-            ok: false,
-            problem: "invalid",
-            message: "That does not look like a connection string (expected postgresql://...).",
-        };
-    }
-    if (DIRECT_CONNECTION_HOST.test(url.hostname)) {
-        return {
-            ok: false,
-            problem: "direct-connection",
-            faqId: "db-url-direct-connection",
-            message: `${url.hostname} is the direct connection host. It only answers on ` +
-                "IPv6, and most campus/home networks are IPv4. Copy the Session " +
-                "pooler string instead — Database settings → Connection string → " +
-                "Session pooler.",
-        };
-    }
-    if (url.port === TRANSACTION_POOLER_PORT) {
-        return {
-            ok: false,
-            problem: "transaction-pooler",
-            faqId: "db-url-transaction-pooler",
-            message: "Port 6543 is the Transaction pooler, meant for serverless — it " +
-                "breaks prepared statements (drizzle-kit hangs). Use the Session " +
-                "pooler on port 5432 instead.",
-        };
-    }
-    return { ok: true };
-}

package/dist/db/run.d.ts

@@ -1,68 +0,0 @@
-export declare function typesFile(): string;
-/** Spawn a pnpm command with inherited stdio; resolves to the exit code. Pass
- * `env` to run the child against a loaded tier rather than process.env. */
-export declare function run(args: string[], env?: NodeJS.ProcessEnv): Promise<number>;
-export interface RunWithStderrResult {
-    code: number;
-    stderr: string;
-}
-/** Spawn a pnpm command while echoing and retaining stderr for diagnostics.
- * Pass `env` to run the child against a loaded tier rather than process.env. */
-export declare function runWithStderr(args: string[], env?: NodeJS.ProcessEnv): Promise<RunWithStderrResult>;
-/** Spawn a pnpm command, capture stdout, throw on non-zero exit. */
-export declare function capture(args: string[]): Promise<string>;
-/** `pnpm exec supabase …` with inherited stdio. */
-export declare const supabase: (...args: string[]) => Promise<number>;
-/** `pnpm exec supabase …` with captured stdout. */
-export declare const supabaseCapture: (...args: string[]) => Promise<string>;
-/**
- * Generate and write Database types from the session's database.
- *
- * Delegates to `@devdogsuga/db/typegen`'s `generateDatabaseTypes`, which runs
- * `pnpm exec supabase gen types --db-url <dbUrl>` (always `--db-url` — the
- * session's own connection string, never the supabase CLI's
- * `--local`/`--linked` modes, whose defaults can disagree with what this
- * process entered; see `db/connection.ts`'s header) and formats the result
- * with `pnpm exec prettier --write`, both run against `findRepoRoot()` so the
- * workspace-pinned CLI versions are what actually run.
- */
-export declare function generateTypes(dbUrl: string): Promise<number>;
-/**
- * `supabase db push` over `dbUrl`, inherited stdio, resolving to the exit code.
- *
- * The one spelling of the migration push, shared by the contributor `db
- * migrate` path (`stack.ts`'s `pushMigrations`) and CI's `deploy migrate`.
- * `--yes` is the unattended apply CI wants; the contributor path omits it so a
- * human still confirms. Neither variant regenerates types — that is
- * `pushMigrations`' own second step, layered on top only where a checkout is
- * meant to be rewritten. A CI apply must NOT write back into the repo, which is
- * exactly why the bare push is factored out here rather than reused whole.
- */
-export declare function dbPush(dbUrl: string, opts?: {
-    yes?: boolean;
-}): Promise<number>;
-/**
- * `supabase db push --dry-run` over `dbUrl`, returning the plan text (stdout
- * and stderr combined, as the workflow's old `2>&1` did).
- *
- * Throws on a non-zero exit — which for a dry run means the CONNECTION failed,
- * not that the plan came back empty. That throw is the invariant `deploy plan`
- * leans on, and the thing the old shell needed `set -o pipefail` to preserve: a
- * dead connection must fail the step rather than read as "no migrations to
- * apply". The child's own output is surfaced in the thrown message, because for
- * a dry run that output is precisely the reason the operator needs.
- */
-export declare function dbPushDryRun(dbUrl: string): Promise<string>;
-/**
- * `seed buckets` takes no `--db-url` (verified against the supabase 2.115.0
- * CLI) — it drives the Storage API, not Postgres — so it is the one data
- * command still keyed on local-vs-hosted rather than on the session's URL.
- */
-export type BucketsConnection = {
-    kind: "local";
-} | {
-    kind: "remote";
-    projectRef: string | undefined;
-};
-/** Seed storage buckets on the local stack or a resolved tier's project. */
-export declare function seedBuckets(conn: BucketsConnection): Promise<number>;

package/dist/db/run.js

@@ -1,156 +0,0 @@
-/**
- * Shared helpers for running supabase CLI and pnpm commands from the repo root.
- *
- * The supabase CLI is a workspace devDependency (not a global install), so
- * every invocation goes through `pnpm exec supabase`. The cwd is always
- * findRepoRoot(), where `supabase/config.toml` lives.
- */
-import { execFile, spawn as nodeSpawn } from "node:child_process";
-import { join } from "node:path";
-import { promisify } from "node:util";
-import { findRepoRoot } from "../repo/root.js";
-import { loadDbTypegen } from "../repo/peers.js";
-const runFile = promisify(execFile);
-export function typesFile() {
-    return join(findRepoRoot(), "packages", "supabase", "src", "database.types.ts");
-}
-/** Spawn a pnpm command with inherited stdio; resolves to the exit code. Pass
- * `env` to run the child against a loaded tier rather than process.env. */
-export function run(args, env) {
-    return new Promise((resolve) => {
-        const child = nodeSpawn("pnpm", args, {
-            stdio: "inherit",
-            cwd: findRepoRoot(),
-            ...(env ? { env } : {}),
-        });
-        child.on("error", (error) => {
-            process.stderr.write(`${error.message}\n`);
-            resolve(1);
-        });
-        child.on("exit", (code) => resolve(code ?? 1));
-    });
-}
-/** Spawn a pnpm command while echoing and retaining stderr for diagnostics.
- * Pass `env` to run the child against a loaded tier rather than process.env. */
-export function runWithStderr(args, env) {
-    return new Promise((resolve) => {
-        const child = nodeSpawn("pnpm", args, {
-            stdio: ["inherit", "inherit", "pipe"],
-            cwd: findRepoRoot(),
-            ...(env ? { env } : {}),
-        });
-        let stderr = "";
-        child.stderr.setEncoding("utf8");
-        child.stderr.on("data", (chunk) => {
-            stderr += chunk;
-            process.stderr.write(chunk);
-        });
-        child.on("error", (error) => {
-            const message = `${error.message}\n`;
-            stderr += message;
-            process.stderr.write(message);
-            resolve({ code: 1, stderr });
-        });
-        child.on("exit", (code) => resolve({ code: code ?? 1, stderr }));
-    });
-}
-/** Spawn a pnpm command, capture stdout, throw on non-zero exit. */
-export async function capture(args) {
-    const { stdout } = await runFile("pnpm", args, {
-        cwd: findRepoRoot(),
-        encoding: "utf8",
-    });
-    return stdout;
-}
-/** `pnpm exec supabase …` with inherited stdio. */
-export const supabase = (...args) => run(["exec", "supabase", ...args]);
-/** `pnpm exec supabase …` with captured stdout. */
-export const supabaseCapture = (...args) => capture(["exec", "supabase", ...args]);
-/**
- * Generate and write Database types from the session's database.
- *
- * Delegates to `@devdogsuga/db/typegen`'s `generateDatabaseTypes`, which runs
- * `pnpm exec supabase gen types --db-url <dbUrl>` (always `--db-url` — the
- * session's own connection string, never the supabase CLI's
- * `--local`/`--linked` modes, whose defaults can disagree with what this
- * process entered; see `db/connection.ts`'s header) and formats the result
- * with `pnpm exec prettier --write`, both run against `findRepoRoot()` so the
- * workspace-pinned CLI versions are what actually run.
- */
-export async function generateTypes(dbUrl) {
-    try {
-        const { generateDatabaseTypes } = await loadDbTypegen();
-        await generateDatabaseTypes({
-            dbUrl,
-            outFile: typesFile(),
-            cwd: findRepoRoot(),
-        });
-    }
-    catch {
-        return 1;
-    }
-    return 0;
-}
-/**
- * `supabase db push` over `dbUrl`, inherited stdio, resolving to the exit code.
- *
- * The one spelling of the migration push, shared by the contributor `db
- * migrate` path (`stack.ts`'s `pushMigrations`) and CI's `deploy migrate`.
- * `--yes` is the unattended apply CI wants; the contributor path omits it so a
- * human still confirms. Neither variant regenerates types — that is
- * `pushMigrations`' own second step, layered on top only where a checkout is
- * meant to be rewritten. A CI apply must NOT write back into the repo, which is
- * exactly why the bare push is factored out here rather than reused whole.
- */
-export function dbPush(dbUrl, opts = {}) {
-    const args = ["db", "push", "--db-url", dbUrl];
-    if (opts.yes)
-        args.push("--yes");
-    return supabase(...args);
-}
-/**
- * `supabase db push --dry-run` over `dbUrl`, returning the plan text (stdout
- * and stderr combined, as the workflow's old `2>&1` did).
- *
- * Throws on a non-zero exit — which for a dry run means the CONNECTION failed,
- * not that the plan came back empty. That throw is the invariant `deploy plan`
- * leans on, and the thing the old shell needed `set -o pipefail` to preserve: a
- * dead connection must fail the step rather than read as "no migrations to
- * apply". The child's own output is surfaced in the thrown message, because for
- * a dry run that output is precisely the reason the operator needs.
- */
-export async function dbPushDryRun(dbUrl) {
-    try {
-        const { stdout, stderr } = await runFile("pnpm", ["exec", "supabase", "db", "push", "--db-url", dbUrl, "--dry-run"], { cwd: findRepoRoot(), encoding: "utf8", maxBuffer: 32 * 1024 * 1024 });
-        return `${stdout}${stderr}`;
-    }
-    catch (err) {
-        const e = err;
-        const detail = `${e.stdout ?? ""}${e.stderr ?? ""}`.trim();
-        throw new Error(detail
-            ? `supabase db push --dry-run failed:\n${detail}`
-            : (e.message ?? "supabase db push --dry-run failed"));
-    }
-}
-/** Seed storage buckets on the local stack or a resolved tier's project. */
-export async function seedBuckets(conn) {
-    if (conn.kind === "local") {
-        return supabase("seed", "buckets", "--local", "--yes");
-    }
-    // Surfaced here, before the supabase CLI ever runs, rather than left for it
-    // to reject: an empty `--project-ref ""` is exactly the kind of ambiguous
-    // failure this whole module exists to avoid.
-    if (!conn.projectRef) {
-        process.stderr.write("devtools db: seed buckets against a hosted project needs PROJECT_REF in the session's env file.\n");
-        return 1;
-    }
-    // `seed buckets` (unlike `config push`) rejects a bare `--project-ref` as
-    // ambiguous with `--local` and demands `--linked` alongside it. That does
-    // NOT mean it needs an ambient `supabase link` state on disk — verified
-    // empirically in an unlinked checkout, `--project-ref` names the target
-    // directly and `--linked` is just the mode selector for "use that ref",
-    // not "use whatever `supabase link` last remembered". So this stays
-    // consistent with `db/connection.ts`'s rule of never depending on
-    // `--linked`'s persisted state.
-    return supabase("seed", "buckets", "--project-ref", conn.projectRef, "--linked");
-}

package/dist/db/seed-buckets.d.ts

@@ -1,2 +0,0 @@
-import { type BucketsConnection } from "./run.js";
-export declare function runSeedBuckets(conn: BucketsConnection): Promise<number>;

package/dist/db/seed-buckets.js

@@ -1,4 +0,0 @@
-import { seedBuckets } from "./run.js";
-export async function runSeedBuckets(conn) {
-    return seedBuckets(conn);
-}

package/dist/db/seed-production.d.ts

@@ -1,8 +0,0 @@
-/** Injectable so a test can fake the connection without a real Postgres. */
-export interface SeedProductionDb {
-    unsafe(query: string): Promise<unknown>;
-    end(): Promise<void>;
-}
-export declare function runSeedProduction(dbUrl: string, deps?: {
-    connect: (url: string) => SeedProductionDb;
-}): Promise<number>;

package/dist/db/seed-production.js

@@ -1,79 +0,0 @@
-/**
- * `db seed production` — apply `supabase/seed/production/*.sql` to a target.
- *
- * The DevDogsUGA repo splits its seeds into `supabase/seed/production/`
- * (the role catalogue and the officer board — content every tier needs)
- * and `supabase/seed/development/` (password-login personas and a worked
- * moderation report — local-dev-only, never meant to reach a hosted
- * target). `db reset` used to run both, but only ever against a LOCAL
- * stack, back when `detectLocalInstance()` was the only way this CLI found
- * a database at all. The session system changed that: `db reset` now runs
- * against any tier, including staging and production, so a reset there
- * explicitly passes `--no-seed` to the Supabase CLI and calls this function
- * itself afterward (see `stack.ts`'s `reset()`) — the config-derived
- * `[db.seed]` list is no longer trusted to keep development's seeds off a
- * hosted target on its own. `production/` is also what a staging or
- * production target needs applied WITHOUT a reset — an already-migrated
- * database that only needs this content refreshed — which is this command's
- * other, still-current use: run it directly, instead of hand-picking files
- * with `db query --file`.
- *
- * That is a deliberate departure from `runSeedRoles` (`seed-roles.ts`),
- * which pipes its one file through `supabase db query --file --db-url`.
- * `03_officers.sql` is many separate `insert into` statements in one file,
- * and the supabase CLI's `db query` runs its `--file` argument as a single
- * PREPARED statement — confirmed against the local stack, where it fails
- * every multi-statement seed file with "cannot insert multiple commands
- * into a prepared statement". `01_roles.sql` only ever worked through that
- * path because it happens to be one big `with … insert … select`
- * statement. So this connects directly with `postgres` (`prepare: false`,
- * the same setting `planner/db.ts` uses and for the same reason: the
- * simple query protocol, not the extended one, is what allows more than
- * one statement per round trip) and runs each file's raw text, rather than
- * shelling out per file.
- */
-import { readdirSync, readFileSync } from "node:fs";
-import { join } from "node:path";
-import postgres from "postgres";
-import { findRepoRoot } from "../repo/root.js";
-const SEED_DIR = "production";
-// Lazy, like seed-roles.ts's `seedFiles()` — computed inside
-// `runSeedProduction`, not at module load, so importing this file never
-// calls `findRepoRoot()` (or touches the filesystem) on its own.
-function seedFiles() {
-    const dir = join(findRepoRoot(), "supabase", "seed", SEED_DIR);
-    return readdirSync(dir)
-        .filter((name) => name.endsWith(".sql"))
-        .sort()
-        .map((name) => join(dir, name));
-}
-/** Real connection: `prepare: false` so multi-statement files run over the
- * simple query protocol instead of gotrue's `db query --file` prepared-
- * statement path, which refuses them. `max: 1` — this is a short-lived,
- * sequential CLI invocation, never a pool. */
-function connect(dbUrl) {
-    const sql = postgres(dbUrl, { max: 1, prepare: false, connect_timeout: 15 });
-    return {
-        unsafe: (query) => sql.unsafe(query),
-        end: () => sql.end({ timeout: 5 }),
-    };
-}
-export async function runSeedProduction(dbUrl, deps = { connect }) {
-    const db = deps.connect(dbUrl);
-    try {
-        for (const file of seedFiles()) {
-            try {
-                await db.unsafe(readFileSync(file, "utf8"));
-            }
-            catch (err) {
-                process.stderr.write(`devtools db seed production: ${file} failed: ` +
-                    `${err instanceof Error ? err.message : String(err)}\n`);
-                return 1;
-            }
-        }
-        return 0;
-    }
-    finally {
-        await db.end();
-    }
-}

package/dist/db/seed-roles.d.ts

@@ -1,7 +0,0 @@
-/**
- * Always `--db-url` — the session's own connection string, never the
- * supabase CLI's `--local`/`--linked` modes. `db query`, which this runs
- * through, supports it the same way `db reset`/`db push` do. See
- * `db/connection.ts`'s header.
- */
-export declare function runSeedRoles(dbUrl: string): Promise<number>;

package/dist/db/seed-roles.js

@@ -1,33 +0,0 @@
-/**
- * `db seed roles` — reconcile platform's role catalogue against a target.
- *
- * Runs 01_roles.sql, the complete built-in and organizational role catalogue,
- * against the chosen target. It never assigns Root: bootstrapping that
- * break-glass role requires the explicit, service-key-backed grant-root command.
- */
-import { join } from "node:path";
-import { findRepoRoot } from "../repo/root.js";
-import { supabase } from "./run.js";
-// Lazy — computed inside `runSeedRoles`, not at module load, so importing
-// this file never calls `findRepoRoot()` on its own (it used to, as a
-// top-level `const`, which broke `--help`/`setup` outside a repo — see
-// `workers.ts`'s header for the general pattern this follows).
-function seedFiles() {
-    return [
-        join(findRepoRoot(), "supabase", "seed", "production", "01_roles.sql"),
-    ];
-}
-/**
- * Always `--db-url` — the session's own connection string, never the
- * supabase CLI's `--local`/`--linked` modes. `db query`, which this runs
- * through, supports it the same way `db reset`/`db push` do. See
- * `db/connection.ts`'s header.
- */
-export async function runSeedRoles(dbUrl) {
-    for (const file of seedFiles()) {
-        const code = await supabase("db", "query", "--file", file, "--db-url", dbUrl);
-        if (code !== 0)
-            return code;
-    }
-    return 0;
-}

package/dist/db/session-refresh.d.ts

@@ -1,43 +0,0 @@
-/**
- * BUG 2 fix: keeping this process's environment in sync with the local
- * stack's lifecycle.
- *
- * `launch.ts` enters a deploy tier into `process.env` exactly ONCE, before
- * `cli.ts` ever dispatches a command. `db start` (`startLocalStack`, in
- * `../stack.ts`) then writes a NEW `.env.generated` — the running stack's
- * fresh connection block — and `db stop` (`stopLocalStack`) deletes it. Left
- * alone, `process.env` keeps whatever it held at launch for the rest of a
- * wizard session: `db start` followed by `db introspect` in the SAME
- * session would still hand `drizzle-kit` the stale (or absent)
- * `.env.generated` values `resolveLocalToolingEnv` reads straight off
- * `process.env` (see `local-env.ts`) — the exact staleness BUG 1 fixed
- * `db introspect` from reading off disk, reappearing one layer up.
- *
- * `refreshSessionEnv` closes that gap by re-running the SAME
- * `enterEnvironment("development", …)` `launch.ts` used at startup —
- * overlay-plus-liveness-probe included — after a stack command that could
- * have changed `.env.generated` succeeds.
- *
- * ⚠️ Guarded to development only. `DEPLOY_ENV` naming a deployed tier means
- * this session targets staging or production (see `../db/connection.ts`);
- * blindly re-entering development here would silently overwrite that tier's
- * connection with local values mid-session, for a stack command
- * (`start`/`stop`/`restart`) that only ever touches the LOCAL Docker stack
- * in the first place.
- */
-import type { EnteredEnvironment } from "@devdogsuga/env/session";
-export interface RefreshSessionEnvOptions {
-    /** Injectable for tests; defaults to `process.env.DEPLOY_ENV`. */
-    deployEnv?: string;
-    /** Injectable for tests; defaults to the real `enterEnvironment`. */
-    enterEnvironment?: (tier: "development", opts: {
-        override: boolean;
-    }) => Promise<EnteredEnvironment>;
-}
-/**
- * Re-enters development — refreshing `process.env` from `.env.generated`'s
- * latest state — when (and only when) this process is already running under
- * development. Returns the one-line note callers report on success, or an
- * empty array when the guard held and nothing needed refreshing.
- */
-export declare function refreshSessionEnv(opts?: RefreshSessionEnvOptions): Promise<string[]>;