@devdogsuga/devtools 0.1.51-next.541 → 0.1.51-next.544

package/dist/{menu-C30rQm5v.js → menu-oQE5IqAI.js}

@@ -1,12 +1,175 @@
-import { d as JSON_FLAG, f as SCOPES, g as positionals, m as createCatalog, p as YES, r as findRepoRoot, s as suppressFailureLog } from "./root-CsocfxnK.js";
-import { E as resolveLayout, _ as loadEnvLoad, a as listContainerNames, g as loadEnv, i as foreignStackProjectId, n as containerPrefix, o as readProjectId, p as supabaseCapture, r as foreignStackMessage, t as STACK_API_PORT, x as devdogsugaRootOrNull } from "./supabase-project-BoJKMCxL.js";
-import { c as reportDevtoolsError, f as isNonInteractive } from "./telemetry-BKFDtzXI.js";
+import { n as execSync } from "./spawn-BvLQzc_K.js";
+import { n as discoverRepoRoot } from "./root-PA8K5G2d.js";
+import { C as containerPrefix, D as readProjectId, E as listContainerNames, P as resolveLayout, S as STACK_API_PORT, T as foreignStackProjectId, d as loadEnvLoad, k as devdogsugaRootOrNull, s as supabaseCapture, u as loadEnv, w as foreignStackMessage } from "./run-CRBte7p0.js";
+import { d as YES, f as createCatalog, i as suppressFailureLog, l as JSON_FLAG, m as positionals, u as SCOPES } from "./failure-log-MSdCgvLc.js";
+import { l as reportDevtoolsError, p as isNonInteractive } from "./telemetry-BDTAGquh.js";
 import { existsSync, readFileSync } from "node:fs";
 import { dirname, join, resolve } from "node:path";
 import { z } from "zod";
 import { cancel, confirm, isCancel, log, note, select, text } from "@clack/prompts";
 import { writeFile } from "node:fs/promises";
-import { execFileSync } from "node:child_process";
+//#region ../cli-core/src/environment.ts
+/**
+* What this machine currently is, read once before the menu draws itself.
+*
+* The wizard used to offer the same commands to everyone: someone whose Docker
+* daemon was not running was invited to reset a database that could not
+* answer, and someone whose stack was already up had no way to stop it at all,
+* because "stop" was not in the tree. Both are the same bug. The menu
+* described the CLI rather than the situation.
+*
+* So this reads three facts and `menu.ts` adapts to them. The facts are few
+* and cheap on purpose; see `probeEnvironment` for the budget and why.
+*
+* ## Unknown is not "no"
+*
+* Every probe can come back `"unknown"`, and that is what a failed probe
+* reports rather than guessing. Nothing is hidden or flagged on `"unknown"`: a
+* machine this cannot read gets the full menu, exactly as before. A tool that
+* hides a command because a `docker ps` timed out is worse than one that never
+* adapted at all, because the command it hides is the one you were looking
+* for.
+*/
+/**
+* A product repository's root (DogDays, DogPack), set by the launcher in
+* product mode. The probes below read `.env` and `supabase/config.toml` from
+* "the checkout", which in a product is not a DevDogsUGA clone; without this
+* the menu in a product repo died on `RepoNotFoundError` before drawing.
+*/
+let productRoot = null;
+function setEnvironmentRoot(root) {
+	productRoot = root;
+}
+/**
+* Where the probes look. Never throws: a menu that cannot find a checkout
+* should still draw, with the machine's facts marked unknown or "no".
+*/
+function probeRoot() {
+	return productRoot ?? discoverRepoRoot() ?? process.cwd();
+}
+/** The directory holding `supabase/config.toml`, or null when there is none. */
+function probeSupabaseRoot() {
+	if (productRoot !== null) return existsSync(join(productRoot, "supabase", "config.toml")) ? productRoot : null;
+	return discoverRepoRoot() === null ? null : devdogsugaRootOrNull(resolveLayout());
+}
+/**
+* Every probe is bounded, silent, and total.
+*
+* `timeout` because a Docker daemon that is starting up (or a VM that has just
+* been resumed) accepts the connection and then never answers, and the failure
+* that produces is a menu that hangs before printing anything, with no output
+* to explain what it is waiting for.
+*/
+function run(file, args) {
+	try {
+		return execSync(file, args, {
+			cwd: probeRoot(),
+			stdio: [
+				"ignore",
+				"pipe",
+				"ignore"
+			],
+			timeout: 3e3
+		});
+	} catch {
+		return null;
+	}
+}
+/**
+* Reads the machine.
+*
+* Two subprocesses at worst, one when Docker is down, plus an `existsSync`.
+* The budget is "cheaper than the first keystroke", because this runs before
+* the wizard's first screen and anything slower would be paid on every
+* invocation to save a few of them later.
+*
+* It does NOT call `supabase status`, which is the authoritative answer but
+* takes the better part of a second: it shells out through `pnpm exec` and
+* then talks to every service in the stack. `docker ps` answers the only
+* question the menu has (is it up?) in a fraction of that, and the commands
+* that need real credentials go through `resolveInstance` (`instance.ts`),
+* which reads the session's already-entered env at the moment it matters.
+*/
+function probeEnvironment(execute = run) {
+	const envFile = existsSync(join(probeRoot(), ".env")) ? "yes" : "no";
+	const docker = execute("docker", ["info"]) === null ? "no" : "yes";
+	if (docker === "no") return {
+		docker,
+		stack: "no",
+		envFile
+	};
+	const names = execute("docker", [
+		"ps",
+		"--format",
+		"{{.Names}}"
+	]);
+	if (names === null) return {
+		docker,
+		stack: "unknown",
+		envFile
+	};
+	const supabaseRoot = probeSupabaseRoot();
+	const prefix = containerPrefix(supabaseRoot === null ? null : readProjectId(supabaseRoot));
+	return {
+		docker,
+		stack: names.split("\n").some((name) => name.trim().startsWith(prefix)) ? "yes" : "no",
+		envFile
+	};
+}
+/**
+* Whether a `Condition` from the command tree currently holds.
+*
+* The tree declares conditions as strings so that it stays inert data the docs
+* build can render (see `catalog.ts`); this is the one place that knows what
+* they mean. `"unknown"` propagates rather than collapsing to false, and both
+* callers below read it as "do nothing".
+*/
+function holds(condition, env) {
+	switch (condition) {
+		case "docker": return env.docker;
+		case "instance-running": return env.stack;
+		case "instance-stopped":
+			if (env.stack === "unknown") return "unknown";
+			return env.stack === "no" ? "yes" : "no";
+	}
+}
+/**
+* Whether the wizard should offer this command at all.
+*
+* False only for a command whose `when` is definitively unmet: `stop`
+* against a stack that is already stopped. This is reserved for commands that
+* would be *meaningless*, never merely inconvenient: one that would fail with
+* a good error message stays in the menu, because a contributor who cannot
+* find a command they know exists is worse off than one who runs it and is
+* told why it did not work.
+*
+* Hiding is a wizard-only decision. `--help` still lists these, the dispatcher
+* still accepts them, and the generated reference still documents them. The
+* menu is a guide to right now, and those three are the reference.
+*/
+function isOffered(node, env) {
+	return node.when === void 0 || holds(node.when, env) !== "no";
+}
+const LABELS = {
+	yes: "yes",
+	no: "no",
+	unknown: "could not tell"
+};
+/**
+* The three facts, as the wizard's opening note and as `status --local`.
+*
+* Printed before the first question rather than discovered through failures:
+* "Docker running  no" at the top of the screen is the whole explanation for
+* why the database commands below it are flagged, and it costs one glance.
+*/
+function describeEnvironment(env) {
+	return [
+		`Docker running   ${LABELS[env.docker]}`,
+		`Local stack up   ${LABELS[env.stack]}`,
+		`.env present     ${LABELS[env.envFile]}`
+	].join("\n");
+}
+//#endregion
 //#region ../cli-core/src/help.ts
 /**
 * `--help`, one level at a time.
@@ -1497,147 +1660,6 @@ async function resolveDbConnection(opts = {}) {
 	};
 }
 //#endregion
-//#region ../cli-core/src/environment.ts
-/**
-* What this machine currently is, read once before the menu draws itself.
-*
-* The wizard used to offer the same commands to everyone: someone whose Docker
-* daemon was not running was invited to reset a database that could not
-* answer, and someone whose stack was already up had no way to stop it at all,
-* because "stop" was not in the tree. Both are the same bug. The menu
-* described the CLI rather than the situation.
-*
-* So this reads three facts and `menu.ts` adapts to them. The facts are few
-* and cheap on purpose; see `probeEnvironment` for the budget and why.
-*
-* ## Unknown is not "no"
-*
-* Every probe can come back `"unknown"`, and that is what a failed probe
-* reports rather than guessing. Nothing is hidden or flagged on `"unknown"`: a
-* machine this cannot read gets the full menu, exactly as before. A tool that
-* hides a command because a `docker ps` timed out is worse than one that never
-* adapted at all, because the command it hides is the one you were looking
-* for.
-*/
-/**
-* Every probe is bounded, silent, and total.
-*
-* `timeout` because a Docker daemon that is starting up (or a VM that has just
-* been resumed) accepts the connection and then never answers, and the failure
-* that produces is a menu that hangs before printing anything, with no output
-* to explain what it is waiting for.
-*/
-function run(file, args) {
-	try {
-		return execFileSync(file, args, {
-			cwd: findRepoRoot(),
-			encoding: "utf8",
-			stdio: [
-				"ignore",
-				"pipe",
-				"ignore"
-			],
-			timeout: 3e3
-		});
-	} catch {
-		return null;
-	}
-}
-/**
-* Reads the machine.
-*
-* Two subprocesses at worst, one when Docker is down, plus an `existsSync`.
-* The budget is "cheaper than the first keystroke", because this runs before
-* the wizard's first screen and anything slower would be paid on every
-* invocation to save a few of them later.
-*
-* It does NOT call `supabase status`, which is the authoritative answer but
-* takes the better part of a second: it shells out through `pnpm exec` and
-* then talks to every service in the stack. `docker ps` answers the only
-* question the menu has (is it up?) in a fraction of that, and the commands
-* that need real credentials go through `resolveInstance` (`instance.ts`),
-* which reads the session's already-entered env at the moment it matters.
-*/
-function probeEnvironment(execute = run) {
-	const envFile = existsSync(join(findRepoRoot(), ".env")) ? "yes" : "no";
-	const docker = execute("docker", ["info"]) === null ? "no" : "yes";
-	if (docker === "no") return {
-		docker,
-		stack: "no",
-		envFile
-	};
-	const names = execute("docker", [
-		"ps",
-		"--format",
-		"{{.Names}}"
-	]);
-	if (names === null) return {
-		docker,
-		stack: "unknown",
-		envFile
-	};
-	const supabaseRoot = devdogsugaRootOrNull(resolveLayout());
-	const prefix = containerPrefix(supabaseRoot === null ? null : readProjectId(supabaseRoot));
-	return {
-		docker,
-		stack: names.split("\n").some((name) => name.trim().startsWith(prefix)) ? "yes" : "no",
-		envFile
-	};
-}
-/**
-* Whether a `Condition` from the command tree currently holds.
-*
-* The tree declares conditions as strings so that it stays inert data the docs
-* build can render (see `catalog.ts`); this is the one place that knows what
-* they mean. `"unknown"` propagates rather than collapsing to false, and both
-* callers below read it as "do nothing".
-*/
-function holds(condition, env) {
-	switch (condition) {
-		case "docker": return env.docker;
-		case "instance-running": return env.stack;
-		case "instance-stopped":
-			if (env.stack === "unknown") return "unknown";
-			return env.stack === "no" ? "yes" : "no";
-	}
-}
-/**
-* Whether the wizard should offer this command at all.
-*
-* False only for a command whose `when` is definitively unmet: `stop`
-* against a stack that is already stopped. This is reserved for commands that
-* would be *meaningless*, never merely inconvenient: one that would fail with
-* a good error message stays in the menu, because a contributor who cannot
-* find a command they know exists is worse off than one who runs it and is
-* told why it did not work.
-*
-* Hiding is a wizard-only decision. `--help` still lists these, the dispatcher
-* still accepts them, and the generated reference still documents them. The
-* menu is a guide to right now, and those three are the reference.
-*/
-function isOffered(node, env) {
-	return node.when === void 0 || holds(node.when, env) !== "no";
-}
-const LABELS = {
-	yes: "yes",
-	no: "no",
-	unknown: "could not tell"
-};
-/**
-* The three facts, as the wizard's opening note and as `status --local`.
-*
-* Printed before the first question rather than discovered through failures:
-* "Docker running  no" at the top of the screen is the whole explanation for
-* why the database commands below it are flagged, and it costs one glance.
-*/
-function describeEnvironment(env) {
-	return [
-		`Docker running   ${LABELS[env.docker]}`,
-		`Local stack up   ${LABELS[env.stack]}`,
-		`.env present     ${LABELS[env.envFile]}`
-	].join("\n");
-}
-//#endregion
 //#region ../cli-core/src/invocation.ts
 /**
 * Records the fully-resolved argv of the command being run, so the CLI can
@@ -1978,4 +2000,4 @@ async function runMenu(catalog, dispatch, env = probeEnvironment(), options = {}
 	return dispatch(chosen.argv);
 }
 //#endregion
-export { helpPath as A, currentProduct as C, isProductMode as D, activeCatalog as E, renderHelp as M, setProductMode as O, ProductConfigError as S, loadProductConfig as T, bail as _, recordEnteredTier as a, explainError as b, describeEnvironment as c, resolveDbConnection as d, sessionIsLocal as f, setMenuEnvHook as g, realEnvEntryDeps as h, beginInvocation as i, renderCommandList as j, catalog as k, probeEnvironment as l, enterSessionEnvironment as m, bareGroupStartPath as n, recordResolved as o, sessionLabel as p, runMenu as r, reproducibleCommand as s, bareGroupStartFlags as t, nonEmpty as u, errorMessage as v, findProductRoot as w, unwrap as x, explain as y };
+export { renderHelp as A, loadProductConfig as C, catalog as D, setProductMode as E, probeEnvironment as M, setEnvironmentRoot as N, helpPath as O, findProductRoot as S, isProductMode as T, explain as _, recordEnteredTier as a, ProductConfigError as b, nonEmpty as c, sessionLabel as d, enterSessionEnvironment as f, errorMessage as g, bail as h, beginInvocation as i, describeEnvironment as j, renderCommandList as k, resolveDbConnection as l, setMenuEnvHook as m, bareGroupStartPath as n, recordResolved as o, realEnvEntryDeps as p, runMenu as r, reproducibleCommand as s, bareGroupStartFlags as t, sessionIsLocal as u, explainError as v, activeCatalog as w, currentProduct as x, unwrap as y };

package/dist/root-DfH38DFq.js

@@ -0,0 +1,2 @@
+import { n as discoverRepoRoot, t as RepoNotFoundError } from "./root-PA8K5G2d.js";
+export { RepoNotFoundError, discoverRepoRoot };

package/dist/root-PA8K5G2d.js

@@ -0,0 +1,77 @@
+import { existsSync, readFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+//#region ../cli-core/src/repo/root.ts
+/**
+* Where devtools finds the DevDogsUGA checkout it is running against.
+*
+* devtools used to live inside `packages/devtools` of that repo, so its own
+* `import.meta.url` WAS a path into the repo (`PROJECT_ROOT` /
+* `REPO_ROOT` walked up a fixed number of `..` segments from this file).
+* Published as its own package and run through `pnpm dlx`, that assumption
+* breaks: this file's `import.meta.url` points into a dlx cache directory
+* or an isolated `node_modules` tree that has nothing to do with the repo
+* the contributor is standing in.
+*
+* So repo discovery walks up from `process.cwd()` instead, looking for the
+* marker validated in the `devtools-dlx` prototype
+* (`/home/sloan/scratchpad/devdogs/prototypes/devtools-dlx/FINDINGS.md`,
+* experiment 1): a directory containing `pnpm-workspace.yaml` AND whose
+* `package.json` has `"name": "devdogs-monorepo"` (DevDogsUGA) or
+* `"backstage"` (Backstage, which the CLIs also run from; `layout.ts` says
+* what differs). The name check is not redundant — a bare
+* `pnpm-workspace.yaml` matches any pnpm workspace, which devtools should
+* refuse rather than silently "find".
+*/
+/**
+* The `package.json` names a repo root may carry: DevDogsUGA's, and Backstage's
+* (the CLIs run from both; see `layout.ts`).
+*/
+const REPO_MARKER_NAMES = ["devdogs-monorepo", "backstage"];
+var RepoNotFoundError = class extends Error {
+	constructor() {
+		super("run this from inside a DevDogsUGA clone");
+		this.name = "RepoNotFoundError";
+	}
+};
+function looksLikeRepoRoot(dir) {
+	if (!existsSync(join(dir, "pnpm-workspace.yaml"))) return false;
+	try {
+		const pkg = JSON.parse(readFileSync(join(dir, "package.json"), "utf8"));
+		return REPO_MARKER_NAMES.includes(pkg.name);
+	} catch {
+		return false;
+	}
+}
+/**
+* Walks up from `startDir` (default `process.cwd()`) looking for the repo
+* marker. Returns `null` rather than throwing — `findRepoRoot()` below is
+* the throwing convenience most callers want; this is exported for callers
+* (like `setup`) that need to know without failing.
+*/
+function discoverRepoRoot(startDir = process.cwd()) {
+	let dir = startDir;
+	for (;;) {
+		if (looksLikeRepoRoot(dir)) return dir;
+		const parent = dirname(dir);
+		if (parent === dir) return null;
+		dir = parent;
+	}
+}
+let cachedRoot;
+/**
+* The memoized, throwing repo-root lookup. Lazy on purpose: importing this
+* module must never fail just because nothing has called it yet (`setup`
+* and `completions` in `launch.ts` never need a repo at all, and must stay
+* that way — see that file's header comment on why).
+*
+* Resolved once per process: `process.cwd()` does not change mid-invocation
+* for this CLI, and re-walking the filesystem on every call would be pure
+* waste.
+*/
+function findRepoRoot() {
+	if (cachedRoot === void 0) cachedRoot = process.env.DEVTOOLS_TEST_REPO_ROOT ?? discoverRepoRoot();
+	if (cachedRoot === null) throw new RepoNotFoundError();
+	return cachedRoot;
+}
+//#endregion
+export { discoverRepoRoot as n, findRepoRoot as r, RepoNotFoundError as t };