@devdogsuga/devtools 0.1.26 → 0.1.27

package/dist/repo/supabase-project.js

@@ -1,124 +0,0 @@
-/**
- * This repo's Supabase project id — read from `supabase/config.toml` — and
- * the container-name conventions the Supabase CLI derives from it.
- *
- * Shared by `environment.ts`'s adaptive-menu probe (does a stack answer for
- * THIS project?) and the foreign-stack detection in `db/generated-env.ts`
- * and `stack.ts` (does a DIFFERENT project's stack hold the shared ports? —
- * the case where `supabase status -o env` fails not because nothing is
- * running, but because what is running on 127.0.0.1:54321 belongs to
- * another workspace, or to this same repo before/after a `project_id`
- * rename). One project-id reader and one container-name parser, so both
- * questions agree on what "this project" means.
- */
-import { execFileSync } from "node:child_process";
-import { readFileSync } from "node:fs";
-import { join } from "node:path";
-/**
- * Reads `project_id` out of `<repoRoot>/supabase/config.toml`, or `null`
- * when the file is missing or unparsable.
- *
- * Regex, not a TOML parser: it is one line, the shape has been stable
- * across every CLI version this repo has seen, and a parser on a path some
- * callers pay before their first real subprocess is a cost that stays
- * invisible until it is why the tool feels slow.
- */
-export function readProjectId(repoRoot) {
-    try {
-        const path = join(repoRoot, "supabase", "config.toml");
-        const match = /^\s*project_id\s*=\s*"([^"]+)"/m.exec(readFileSync(path, "utf8"));
-        return match?.[1] ?? null;
-    }
-    catch {
-        return null;
-    }
-}
-/**
- * The Supabase CLI's container name prefix for a project id, or the bare
- * `supabase_db_` fallback when the id could not be read.
- *
- * Falling back to the bare prefix means a machine whose `config.toml`
- * cannot be read still detects *a* stack, at the cost of over-matching a
- * differently-named project — deliberate, and unchanged from this
- * function's original home in `environment.ts`: over-matching offers
- * `stop`/a foreign-stack hint for a stack that turns out to be this
- * project's own, which is harmless to see and decline, while
- * under-matching hides a real signal entirely.
- */
-export function containerPrefix(projectId) {
-    return projectId ? `supabase_db_${projectId}` : "supabase_db_";
-}
-/**
- * The local stack's API port, published by its Kong container. Mirrors
- * `@devdogsuga/env/load`'s `LOCAL_STACK_PORT`, which this module cannot import
- * statically (that package is an optional peer, loaded on demand).
- */
-export const STACK_API_PORT = 54321;
-function defaultExec(file, args) {
-    try {
-        return execFileSync(file, args, {
-            encoding: "utf8",
-            stdio: ["ignore", "pipe", "ignore"],
-            timeout: 3000,
-        });
-    }
-    catch {
-        return null;
-    }
-}
-/**
- * `docker ps --format '{{.Names}}'`, split into trimmed, non-empty names —
- * or `null` when Docker could not be read at all (no daemon, not
- * installed, timed out). With `publish`, only the containers publishing that
- * host port. `execute` is injectable for tests, mirroring `environment.ts`'s
- * own probes.
- */
-export function listContainerNames(publish, execute = defaultExec) {
-    const filter = publish === undefined ? [] : ["--filter", `publish=${publish}`];
-    const out = execute("docker", ["ps", ...filter, "--format", "{{.Names}}"]);
-    if (out === null)
-        return null;
-    return out
-        .split("\n")
-        .map((name) => name.trim())
-        .filter((name) => name.length > 0);
-}
-/**
- * Finds the `supabase_kong_<id>` container among `names` whose id differs
- * from `projectId` — the signature of a stack started from a DIFFERENT
- * Supabase project (this same repo before/after a rename, or another
- * project entirely) holding the shared ports. Kong is the container that
- * publishes the API port, so callers pass the names `listContainerNames`
- * returns for `STACK_API_PORT`: that names the stack actually on 54321,
- * not just any Supabase stack on the machine.
- *
- * Returns that foreign id, or `null` when every matching container belongs
- * to this project, none match at all, or `projectId` itself could not be
- * read — with no known id of our own, there is nothing to compare against,
- * and guessing would risk telling a contributor their OWN stack is
- * foreign.
- */
-export function foreignStackProjectId(names, projectId) {
-    if (projectId === null)
-        return null;
-    for (const name of names) {
-        const match = /^supabase_kong_(.+)$/.exec(name);
-        if (!match)
-            continue;
-        const id = match[1];
-        if (id !== projectId)
-            return id;
-    }
-    return null;
-}
-/**
- * The actionable message for a detected foreign stack — shared by
- * `db/generated-env.ts` (a failed `supabase status -o env`) and `stack.ts`
- * (a failed `supabase start`), so both name the same fix in the same
- * words.
- */
-export function foreignStackMessage(foreignProjectId) {
-    return (`The stack on port ${STACK_API_PORT} belongs to project "${foreignProjectId}", not ` +
-        "this checkout's. Stop it with `supabase stop --project-id " +
-        `${foreignProjectId}\` then \`pnpm devtools db start\`.`);
-}

package/dist/repo/tsx-loader.d.ts

@@ -1,6 +0,0 @@
-/**
- * Imports a repo TypeScript file at an absolute path, loaded through tsx.
- * Returns the module namespace, typed as `T` by the caller (there is no way
- * to know the shape of an arbitrary repo file's exports statically here).
- */
-export declare function importRepoTs<T>(absolutePath: string): Promise<T>;

package/dist/repo/tsx-loader.js

@@ -1,41 +0,0 @@
-/**
- * Loads the repo's own TypeScript at runtime: env manifests
- * (each app's `src/env.ts` and friends), cron contracts
- * (each app's `cloudflare/scheduled.ts`), and — via `source.ts` — the
- * `devdogs-source` condition packages (`open-graph`, `email`, `docs`).
- *
- * Uses `tsx`'s programmatic API (`register()` from `tsx/esm/api`), NOT the
- * `--conditions=devdogs-source` CLI flag the old in-repo devtools used —
- * this package ships built JS and runs from `dist/`, so there is no `tsx`
- * process wrapping it anymore (see the package README / CUTOVER note on
- * "built JS, tsx only for repo TS").
- *
- * Gotcha (FINDINGS.md experiments 3 and 4, gotcha C): do NOT pass a
- * `namespace` to `register()`. It silently breaks tsx's own relative
- * `./foo.js` → `./foo.ts` extension-fallback resolution for files loaded
- * under that registration — exactly the convention `open-graph`, `email`,
- * and any future `devdogs-source` package use for their internal relative
- * imports. `register({})` (no options) is the only form validated.
- */
-import { pathToFileURL } from "node:url";
-let registered = false;
-/** Idempotent: registers tsx's ESM loader hooks once per process. */
-async function ensureRegistered() {
-    if (registered)
-        return;
-    const { register } = await import("tsx/esm/api");
-    // `register()`'s return value is an unregister callback (`() => Promise<void>`),
-    // not something this process ever calls: the hooks stay installed for the
-    // CLI's whole lifetime.
-    register();
-    registered = true;
-}
-/**
- * Imports a repo TypeScript file at an absolute path, loaded through tsx.
- * Returns the module namespace, typed as `T` by the caller (there is no way
- * to know the shape of an arbitrary repo file's exports statically here).
- */
-export async function importRepoTs(absolutePath) {
-    await ensureRegistered();
-    return import(pathToFileURL(absolutePath).href);
-}

package/dist/run/pick.d.ts

@@ -1,90 +0,0 @@
-export interface App {
-    name: string;
-    script: string;
-}
-/**
- * Whether to ask at all.
- *
- * Every one of these is a case where a prompt is either impossible or wrong:
- *
- *   * `CI`, set by GitHub Actions and every other runner. No workflow reaches
- *     this today (see the header), but a workflow that blocked on a
- *     multiselect would hang until its timeout with no output saying why, and
- *     that failure is bad enough to keep guarding against.
- *   * No TTY: a pipe, a `pnpm` invoked by a script, an editor task runner.
- *     Nobody is there to answer. Every other picker in this repo checks the
- *     same thing.
- *   * An explicit filter. The caller has already said which packages, and
- *     asking again would be asking them to repeat themselves.
- *   * `DEVDOGS_PICK=0`, the escape hatch and the recursion guard above.
- */
-export declare function shouldAsk(args: string[]): boolean;
-/**
- * Pulls every `--filter`/`-F`/`--scope` value out of `args`, returning the
- * package patterns named and the remaining args with those flags removed.
- *
- * `--scope` is folded into the same bucket as `--filter` here: pnpm has no
- * `--scope` flag of its own, so a caller who still types the turbo-era name
- * gets it translated into a real `--filter` value rather than passed through
- * to a `pnpm` invocation that would reject it outright.
- *
- * Exported for the same reason `parseTierArg` is: pure, no `process.exit`, so
- * it is unit-testable without going through `passthrough`.
- */
-export declare function extractFilters(args: readonly string[]): {
-    filters: string[];
-    rest: string[];
-};
-export interface DevPlan {
-    /** Apps whose dev server is `vinext dev`, started directly, one each. */
-    vinext: string[];
-    /** The `pnpm` args for every other selected app's `dev`, or null for none. */
-    others: string[] | null;
-}
-/**
- * Splits a `dev` run between apps whose dev server is `vinext dev` and the
- * rest.
- *
- * A vinext app's server code runs in workerd, which only sees what
- * `@cloudflare/vite-plugin` hands it: the app dir's own `.dev.vars`/`.env`, or
- * with `CLOUDFLARE_INCLUDE_PROCESS_ENV` the whole `process.env`. The repo's
- * `.env` is at the root, so through the app's own `with-env vinext dev` script
- * the Worker gets nothing and env validation fails. So a vinext app skips its
- * script and runs `pnpm --filter <app> exec vinext dev` with the env
- * `scopedProcessEnv` builds, the same way `workflows run` starts one: the
- * flag set, and every other app's variables left out. Its script's own
- * `with-env` would load the whole `.env` back in, so it is not used.
- *
- * Everything else still runs its own `dev` script under one `pnpm --parallel`.
- * `apps` is every app with a `dev` script; `filters` the selection (empty for
- * all of them). Only apps are named here: no other package has a `dev`
- * script.
- */
-export declare function planDev(apps: readonly App[], filters: readonly string[], rest: readonly string[]): DevPlan;
-export interface TierArgResult {
-    /** The validated tier, or absent when `--tier` was not passed. */
-    tier?: string;
-    /** `args` with `--tier` and its value removed, so pnpm never sees them. */
-    rest: string[];
-    /** Set instead of `tier` when parsing failed; `rest` is unchanged on error. */
-    error?: string;
-}
-/**
- * Parses and strips `--tier <value>` from pnpm-bound args, mirroring the
- * `--all` strip above.
- *
- * Pure on purpose — no `process.exit` — so this is unit-testable without
- * going through `passthrough`, which every other path in this file ends at
- * and which a test cannot observe return from. `runTask` is the one caller,
- * and it is the one that turns `error` into an exit.
- */
-export declare function parseTierArg(args: readonly string[]): TierArgResult;
-/**
- * Runs one root task, asking which apps first where that makes sense.
- *
- * Never returns: every path ends in `passthrough`, which exits with the
- * underlying `pnpm` invocation's own status. That is why `cli.ts` dispatches
- * this before `intro()`. There is no `outro()` to reach, and a banner would
- * land on the stream a dev server is about to take over.
- */
-export declare function runTask(argv: string[]): Promise<never>;