@rebasepro/cli 0.16.0 → 0.16.1-canary.g0d7af95

package/dist/bundle.d.ts

@@ -1,4 +1,4 @@
-import { type DeclaredStorageSources, type NativeDependency, type RebaseBundleManifest, type RebaseBackendAppConfig } from "@rebasepro/types";
+import { type ResourceGraph, type NativeDependency, type RebaseBundleManifest, type RebaseBackendAppConfig } from "@rebasepro/types";
 export declare const DEFAULT_BUNDLE_DIR = "dist-bundle";
 export interface BuildBundleOptions {
     projectRoot: string;
@@ -14,7 +14,14 @@ export interface BuildBundleOptions {
      * Passed in rather than re-read here so `rebase.json` is parsed and validated
      * once, by the command that owns it.
      */
-    storage?: DeclaredStorageSources;
+    /**
+     * The project's resource graph, derived from its config.
+     *
+     * Recorded in the bundle manifest so a host can read what the project needs
+     * without running it — which is what lets a console show "wants a `media`
+     * bucket, has none" before a first deploy has produced anything.
+     */
+    resources?: ResourceGraph;
     /**
      * Install the declared dependencies into the bundle at build time.
      *
@@ -193,6 +200,25 @@ export interface VendorResult {
  * the upload is compressed: crossing it means "getting close", not "will fail".
  */
 export declare const VENDOR_SIZE_WARN_BYTES: number;
+/**
+ * Where vendoring stops being an optimisation and becomes a bundle nobody can
+ * deploy.
+ *
+ * Past this, shipping the tree anyway trades a faster cold start for a 413 — and
+ * the 413 arrives at deploy time, after a build nobody watches, with a remedy
+ * (`--no-vendor`) that requires knowing this happened. Unvendoring here costs
+ * 40–60s of cold start and produces a bundle that uploads; that is the better
+ * side of the trade to be on by default.
+ *
+ * 200 MB assumes a **2x** floor on compression, which is pessimistic for a tree
+ * of JavaScript (3–5x is typical) and deliberately so: source maps and prebuilt
+ * binaries compress far worse than source, and the failure this prevents is
+ * asymmetric — a bundle refused at the door versus a minute of cold start.
+ * `--vendor` overrides it, for a deploy path with no upload at all (a Dockerfile
+ * built from source, where the tree is copied into an image and the control
+ * plane never sees it).
+ */
+export declare const VENDOR_SIZE_MAX_BYTES: number;
 /**
  * Install the bundle's declared dependencies into the bundle itself.
  *

package/dist/commands/build.d.ts

@@ -1 +1,11 @@
+import type { RebaseAppConfig } from "@rebasepro/types";
 export declare function buildCommand(rawArgs?: string[]): Promise<void>;
+/**
+ * Build a static app and package it into a static bundle.
+ *
+ * Runs the app's own build command, checks it produced the declared output, then
+ * packages that output into a `static`-kind bundle — the same deployable shape as
+ * a backend bundle, so a frontend or admin app deploys through the identical
+ * path and runs on the identical image, just serving files instead of an API.
+ */
+export declare function buildAssetApp(projectRoot: string, name: string, app: RebaseAppConfig, runtimeRange: string, outOverride?: string): Promise<string | undefined>;

package/dist/commands/cloud/context.d.ts

@@ -139,6 +139,7 @@ export declare const GLOBAL_CLOUD_FLAGS: {
     readonly "--yes": BooleanConstructor;
     readonly "--help": BooleanConstructor;
     readonly "--project": StringConstructor;
+    readonly "--url": StringConstructor;
     readonly "-p": "--project";
     readonly "-y": "--yes";
     readonly "-h": "--help";
@@ -192,7 +193,22 @@ export declare function printJson(value: unknown): void;
  * (and nothing else); otherwise run `human`. Keeping the two behind a single
  * call is what guarantees a command can never print a table AND a JSON blob.
  */
-export declare function emit(human: () => void, json: unknown): void;
+export declare function emit<T>(human: () => void, json: JsonArg<T>): void;
+/**
+ * The JSON payload, which must be a value and not a producer of one.
+ *
+ * `json: unknown` accepted a function without complaint, and four call sites in
+ * `resources.ts` passed `() => ({ … })` — mirroring the human argument beside
+ * it, which *is* a thunk. In JSON mode `printJson` then stringified a function,
+ * which is `undefined`. So `rebase cloud resources`, `resources set` and two
+ * cluster commands printed the single word `undefined` on every piped or
+ * `--json` run — and since this family forces JSON mode off a TTY, that is
+ * every scripted use of them.
+ *
+ * Typed so the mistake cannot be made again: a function resolves the parameter
+ * to `never`, and the call site fails to compile.
+ */
+export type JsonArg<T> = T extends (...args: never[]) => unknown ? never : T;
 /**
  * Print a help page — the human one, or a machine-readable description of the
  * same command in JSON mode.

package/dist/commands/cloud/databases.d.ts

@@ -30,6 +30,7 @@ export declare function resolveBackupArgs(rawArgs: string[]): {
         readonly "--yes": BooleanConstructor;
         readonly "--help": BooleanConstructor;
         readonly "--project": StringConstructor;
+        readonly "--url": StringConstructor;
         readonly "-p": "--project";
         readonly "-y": "--yes";
         readonly "-h": "--help";

package/dist/commands/cloud/deploy.d.ts

@@ -1,3 +1,17 @@
+/**
+ * `rebase cloud deploy` and `rebase cloud logs`.
+ *
+ * `deploy` triggers the control-plane `deploy` function, then tails the build
+ * logs from the deployment record until it succeeds or fails. `logs` shows the
+ * latest build log, or runtime logs with `--runtime`.
+ *
+ * There are three deploys behind the one verb, and which one runs depends on the
+ * flags: `--bundle` builds and uploads a managed bundle, `--source .` uploads
+ * this directory as a build context, and the bare form uploads nothing and asks
+ * the control plane to rebuild what it already holds. That last one is the
+ * dangerous one — see `planBareDeploy`.
+ */
+import arg from "arg";
 /** A project row, reduced to what says how it deploys (camel or snake columns). */
 export interface DeployProjectRow {
     runtimeMode?: string;
@@ -110,5 +124,49 @@ export declare function ejectRefusal(opts: EjectContext, projectRef: string): {
 export declare function deployWarnings(opts: EjectContext, projectRef: string): DeployWarning[];
 /** The warning half of a deploy's JSON payload — merged into whatever it emits. */
 export declare function warningPayload(warnings: DeployWarning[]): Record<string, unknown>;
+/**
+ * `rebase cloud deploy [app]` — its flags, and which app of this repository the
+ * line named.
+ *
+ * Parsed through `parseCloudArgs` rather than `arg` directly, and the reason is
+ * the positional. This command used to parse `rawArgs.slice(2)` permissively
+ * and read `_[0]` as the app name — but `rawArgs` is the WHOLE `process.argv`,
+ * so `_` opens with the command words themselves. `_[0]` was therefore the
+ * literal string `"cloud"` on every run, which then went to `selectDeployApp`
+ * and came back as:
+ *
+ *   This repository declares no app named "cloud". It declares: backend, web.
+ *
+ * So the documented `rebase cloud deploy --bundle` failed on every project that
+ * did not happen to declare an app called `cloud`, `rebase cloud deploy web`
+ * could not reach `web`, and the refusal named the user's real apps — reading
+ * as a fault in their `rebase.json` rather than in the CLI's own parse.
+ *
+ * `commandWords` counts from `cloud` itself, so `cloud deploy` is 2, and it is
+ * applied to the PARSED positionals: a flag written before the group no longer
+ * shifts the app name either.
+ */
+export declare function resolveDeployArgs(rawArgs: string[]): {
+    flags: arg.Result<{
+        "--no-follow": BooleanConstructor;
+        "--source": StringConstructor;
+        "--message": StringConstructor;
+        "--bundle": BooleanConstructor;
+        "--bundle-dir": StringConstructor;
+        "--skip-type-check": BooleanConstructor;
+        "--force": BooleanConstructor;
+        "-m": string;
+    } & {
+        readonly "--json": BooleanConstructor;
+        readonly "--yes": BooleanConstructor;
+        readonly "--help": BooleanConstructor;
+        readonly "--project": StringConstructor;
+        readonly "--url": StringConstructor;
+        readonly "-p": "--project";
+        readonly "-y": "--yes";
+        readonly "-h": "--help";
+    }>;
+    appName: string | undefined;
+};
 export declare function deployCommand(rawArgs: string[], projectRef: string): Promise<void>;
 export declare function logsCommand(rawArgs: string[], projectRef: string): Promise<void>;

package/dist/commands/cloud/deployments.d.ts

@@ -37,6 +37,47 @@ export declare function triggerInfo(dep: DeploymentRow): {
 };
 /** Shape one deployment row into the stable JSON view the CLI publishes. */
 export declare function deploymentView(dep: DeploymentRow): Record<string, unknown>;
+/** What `POST /api/functions/deploy/cancel` answers. */
+export interface CancelResponse {
+    success: boolean;
+    /**
+     * The deployment that was cancelled — `null` when there was none.
+     *
+     * Nullable because "nothing was in flight" is a real, successful outcome
+     * and not an error: a project's `status` column can claim `deploying` while
+     * no deployment row backs the claim, and cancelling is what clears it.
+     */
+    deploymentId: string | null;
+    buildJobDeleted: boolean;
+    /** The request cleared a stuck `deploying` claim rather than stopping a build. */
+    unstranded?: boolean;
+    /** The status the project settled on when it did. */
+    projectStatus?: string | null;
+}
+/**
+ * What `rebase cloud cancel` says it did.
+ *
+ * Split out of the command because there are now two outcomes behind one
+ * `success: true`, and only one of them is "a build was stopped". The control
+ * plane learned to clear a project stranded at `deploying` with no deployment
+ * row behind it — the state `prospector` was wedged in for five days — and it
+ * reports that through this same endpoint. An unbranched caller printed
+ * "Cancelled deployment null" for it, which reads as a bug in the thing that
+ * had just fixed the bug.
+ *
+ * The ABSENT ID is what decides, not the `unstranded` flag: the flag is the
+ * server being explicit, and it is the newer half of the contract. Branching on
+ * the id means a client that meets a control plane which grew the behaviour
+ * without the flag still says something true.
+ */
+export declare function cancelView(res: CancelResponse): {
+    /** The headline, for `success()`. */
+    headline: string;
+    /** Dimmed follow-ups, printed under it. */
+    notes: string[];
+    /** The stable JSON view, which is what a piped run gets. */
+    json: Record<string, unknown>;
+};
 /**
  * Rows shown when `--limit` is not given.
  *
@@ -66,6 +107,7 @@ export declare function resolveDeploymentIdArg(rawArgs: string[], command: strin
         readonly "--yes": BooleanConstructor;
         readonly "--help": BooleanConstructor;
         readonly "--project": StringConstructor;
+        readonly "--url": StringConstructor;
         readonly "-p": "--project";
         readonly "-y": "--yes";
         readonly "-h": "--help";

package/dist/commands/cloud/env.d.ts

@@ -34,6 +34,7 @@ export declare function resolveEnvSetArgs(rawArgs: string[]): {
         readonly "--yes": BooleanConstructor;
         readonly "--help": BooleanConstructor;
         readonly "--project": StringConstructor;
+        readonly "--url": StringConstructor;
         readonly "-p": "--project";
         readonly "-y": "--yes";
         readonly "-h": "--help";

package/dist/commands/cloud/extensions.d.ts

@@ -15,6 +15,7 @@ export declare function resolveExtensionArgs(rawArgs: string[], action: "enable"
         readonly "--yes": BooleanConstructor;
         readonly "--help": BooleanConstructor;
         readonly "--project": StringConstructor;
+        readonly "--url": StringConstructor;
         readonly "-p": "--project";
         readonly "-y": "--yes";
         readonly "-h": "--help";

package/dist/commands/cloud/projects.d.ts

@@ -1,4 +1,4 @@
-import { type DeployTarget, type CloudClient } from "./context";
+import { type DeployTarget, type CloudClient } from "./context.js";
 export declare function listProjects(rawArgs: string[]): Promise<void>;
 /**
  * Where this project says it runs.
@@ -9,8 +9,9 @@ export declare function listProjects(rawArgs: string[]): Promise<void>;
  * never contradicted by a failure; it just sits in the record. The CLI used to
  * default to `hetzner`/`nbg1` unconditionally, which is how projects running on
  * our GKE cluster came to describe themselves as Hetzner in the console — and
- * `provider` is half the Stripe compute lookup key (`compute_<provider>_<vmSize>`),
- * so that is a mispricing, not a cosmetic slip.
+ * `provider` also decides which substrate's rules a project's dials are clamped
+ * to — Autopilot's 250m floor and 1:1-6.5:1 band do not apply on Hetzner or EKS
+ * — so a wrong value here resizes pods, it is not a cosmetic slip.
  *
  * The control plane already publishes the infrastructure that actually exists,
  * and the console's create wizard reads it. Ask the same question here.
@@ -39,10 +40,19 @@ export declare const CREATE_PROJECT_FLAGS: {
     readonly "--branch": StringConstructor;
     readonly "--provider": StringConstructor;
     readonly "--region": StringConstructor;
-    readonly "--vm-size": StringConstructor;
     readonly "--org": StringConstructor;
     readonly "--link": BooleanConstructor;
     readonly "-n": "--name";
+    readonly "--cpu": StringConstructor;
+    readonly "--memory": StringConstructor;
+    readonly "--replicas": StringConstructor;
+    readonly "--spot": StringConstructor;
+    readonly "--scale-to-zero": StringConstructor;
+    readonly "--db-mode": StringConstructor;
+    readonly "--db-instances": StringConstructor;
+    readonly "--db-cpu": StringConstructor;
+    readonly "--db-memory": StringConstructor;
+    readonly "--storage": StringConstructor;
 };
 export declare function createProject(rawArgs: string[]): Promise<void>;
 /**

package/dist/commands/cloud/resources.d.ts

@@ -106,7 +106,16 @@ export declare function resourcesCommand(action: string | undefined, rawArgs: st
  * the same shape `buildSettingsPatch` uses. Returns an error string rather than
  * throwing, because the caller owns how a refusal is printed in JSON mode.
  */
-export declare function buildDialPatch(rawArgs: string[]): {
+export declare function buildDialPatch(rawArgs: string[], 
+/**
+ * `requireOne: false` for `projects create`, where naming no dial is the
+ * ordinary case — a new project takes the platform default. On
+ * `resources set` a patch with nothing in it is a typo, and saying so beats
+ * a success message for a change nobody made.
+ */
+opts?: {
+    requireOne?: boolean;
+}): {
     patch: Record<string, unknown>;
     error?: string;
 };

package/dist/commands/db.d.ts

@@ -13,4 +13,20 @@
  * is actually changed, and leaves the plugin usable on its own terms.
  */
 export declare function absolutizeLocalPathArgs(args: string[], cwd: string): string[];
+/**
+ * Run a database subcommand through the active driver's CLI, throwing on
+ * failure instead of exiting.
+ *
+ * `dbCommand` below turns every failure into `process.exit(1)`, which is right
+ * for a command the user invoked directly and wrong for a caller that has more
+ * to do afterwards — `rebase dev` runs a schema push during start-up and must
+ * survive it failing. Exiting is therefore the wrapper's job, not this
+ * function's.
+ *
+ * The database is resolved *here* rather than in the wrapper, so the schema
+ * push `rebase dev` performs during start-up reaches the managed database too.
+ */
+export declare function runDriverDbCommand(rawArgs: string[], options?: {
+    quiet?: boolean;
+}): Promise<void>;
 export declare function dbCommand(subcommand: string | undefined, rawArgs: string[]): Promise<void>;

package/dist/commands/dev.d.ts

@@ -20,9 +20,20 @@ export declare const DEV_FLAGS: {
     readonly "--frontend-only": BooleanConstructor;
     readonly "--port": NumberConstructor;
     readonly "--generate": BooleanConstructor;
+    /**
+     * Point this run at a database of your own, ahead of everything else.
+     *
+     * The managed development database fills a vacuum; it never redirects a
+     * project that has said which Postgres it wants. This flag is the loudest
+     * way to say it, and outranks DATABASE_URL in the environment and in .env.
+     */
+    readonly "--database-url": StringConstructor;
+    /** Use Postgres in Docker rather than the managed database. */
+    readonly "--docker": BooleanConstructor;
     readonly "-b": "--backend-only";
     readonly "-f": "--frontend-only";
     readonly "-P": "--port";
     readonly "-g": "--generate";
+    readonly "--no-db": BooleanConstructor;
 };
 export declare function devCommand(rawArgs: string[]): Promise<void>;

package/dist/commands/doctor.d.ts

@@ -1,4 +1,4 @@
-import { type LibpqUrlFinding } from "../utils/libpq-url";
+import { type LibpqUrlFinding } from "../utils/libpq-url.js";
 /**
  * Find connection strings libpq cannot parse, anywhere in the project.
  *

package/dist/commands/init.d.ts

@@ -1,4 +1,4 @@
-import type { PackageManager, PMCommands } from "../utils/package-manager";
+import type { PackageManager, PMCommands } from "../utils/package-manager.js";
 /**
  * Every scaffolded file that carries a `{{PLACEHOLDER}}`.
  *

package/dist/commands/resources.d.ts

@@ -0,0 +1 @@
+export declare function resourcesCommand(rawArgs: string[]): Promise<void>;

package/dist/constraints-BK1_4vci.js

@@ -0,0 +1,80 @@
+//#region src/dev-db/constraints.ts
+/**
+* What PGlite can and cannot do as a development database, measured rather
+* than assumed.
+*
+* Everything in this directory is shaped by four facts, each established by
+* running it against `@electric-sql/pglite` 0.5.6 and
+* `@electric-sql/pglite-socket` 0.2.9 rather than by reading their docs. They
+* are recorded here because two of them are silent failures — the kind that
+* make a developer lose an evening to a feature that reports success and does
+* nothing.
+*
+* 1. **It is really PostgreSQL 18.3.** `select version()` over the socket
+*    returns `PostgreSQL 18.3 (PGlite 0.5.6) on wasm32`, which is the same
+*    major as the `postgres:18-alpine` the eject template ships. So a dev
+*    database here and a compose database there are the same Postgres, and
+*    schema behaviour does not diverge between them.
+*
+* 2. **`pg_trgm` and `unaccent` are available**, which is what search
+*    collections need. They are not installed by a bare `CREATE EXTENSION`,
+*    though — PGlite ships them as separate bundles that must be passed to the
+*    constructor, and without that `CREATE EXTENSION pg_trgm` fails with
+*    `extension "pg_trgm" is not available`. {@link PGLITE_EXTENSIONS} is that
+*    list, and it has to stay in step with what the schema generator emits.
+*
+* 3. **RLS is enforced exactly as it is on a real server.** With
+*    `SET LOCAL ROLE "rebase_user"` inside a transaction — which is how
+*    `PostgresBackendDriver` isolates every request — `current_user` becomes
+*    the restricted role, `session_user` stays the owner, and a policy using
+*    `current_setting('app.tenant')` filters rows correctly, including under
+*    `FORCE ROW LEVEL SECURITY`. Measured: an owner saw 3 rows and the
+*    role-switched transaction saw 2, with the cross-tenant probe returning 0.
+*    This is the one that mattered most: a dev database that quietly failed to
+*    apply RLS would give false confidence about the product's central claim.
+*
+* 4. **Concurrency is the real limit, and it fails badly.** PGlite is a single
+*    session, and `PGLiteSocketServer` multiplexes connections onto it. Two
+*    pooled clients that hold *overlapping transactions* deadlock — not error,
+*    hang — which is precisely what a request-per-transaction server does under
+*    any concurrent load. {@link MANAGED_POOL_MAX} is the answer: one client
+*    connection, so requests queue in the pool instead of deadlocking in the
+*    multiplexer. Measured: with a pool of 1, four concurrent queries and a
+*    role-switched RLS transaction all pass; with a pool of 5 the same script
+*    hangs indefinitely.
+*
+* 5. **LISTEN/NOTIFY needed repairing, and now works.** A notification is an
+*    asynchronous message with no request to answer, and the multiplexer hands
+*    it to whichever socket is reading rather than to the one that issued
+*    `LISTEN` — so a dedicated listener connection, which is exactly how the
+*    realtime engine works, received nothing while the *writer* received
+*    notifications it never asked for. `notification-proxy.ts` corrects that by
+*    copying every `NotificationResponse` frame to every client, which for a
+*    single-session database is simply the truth. Realtime therefore works
+*    against the managed database, with no change to the server: it does
+*    ordinary `LISTEN` over ordinary libpq.
+*/
+/**
+* Extensions to hand PGlite's constructor.
+*
+* `CREATE EXTENSION` alone cannot install these — PGlite resolves them from
+* bundles supplied at construction time, so anything missing here is missing
+* from the database no matter what the migration says.
+*/
+var PGLITE_EXTENSION_NAMES = ["pg_trgm", "unaccent"];
+/**
+* Announced at startup, every time, rather than discovered.
+*
+* A developer who does not know realtime is off will read the silence as a bug
+* in their own code, which is a worse outcome than not offering the managed
+* database at all.
+*/
+var MANAGED_LIMITATIONS = [{
+	id: "concurrency",
+	summary: "Requests are served one at a time. Behaviour is correct but serialized, so lock contention and job-queue concurrency cannot be reproduced here.",
+	remedy: "Reproduce concurrency against a real Postgres: rebase dev --docker"
+}];
+//#endregion
+export { PGLITE_EXTENSION_NAMES as n, MANAGED_LIMITATIONS as t };
+
+//# sourceMappingURL=constraints-BK1_4vci.js.map

package/dist/constraints-BK1_4vci.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"constraints-BK1_4vci.js","names":[],"sources":["../src/dev-db/constraints.ts"],"sourcesContent":["/**\n * What PGlite can and cannot do as a development database, measured rather\n * than assumed.\n *\n * Everything in this directory is shaped by four facts, each established by\n * running it against `@electric-sql/pglite` 0.5.6 and\n * `@electric-sql/pglite-socket` 0.2.9 rather than by reading their docs. They\n * are recorded here because two of them are silent failures — the kind that\n * make a developer lose an evening to a feature that reports success and does\n * nothing.\n *\n * 1. **It is really PostgreSQL 18.3.** `select version()` over the socket\n *    returns `PostgreSQL 18.3 (PGlite 0.5.6) on wasm32`, which is the same\n *    major as the `postgres:18-alpine` the eject template ships. So a dev\n *    database here and a compose database there are the same Postgres, and\n *    schema behaviour does not diverge between them.\n *\n * 2. **`pg_trgm` and `unaccent` are available**, which is what search\n *    collections need. They are not installed by a bare `CREATE EXTENSION`,\n *    though — PGlite ships them as separate bundles that must be passed to the\n *    constructor, and without that `CREATE EXTENSION pg_trgm` fails with\n *    `extension \"pg_trgm\" is not available`. {@link PGLITE_EXTENSIONS} is that\n *    list, and it has to stay in step with what the schema generator emits.\n *\n * 3. **RLS is enforced exactly as it is on a real server.** With\n *    `SET LOCAL ROLE \"rebase_user\"` inside a transaction — which is how\n *    `PostgresBackendDriver` isolates every request — `current_user` becomes\n *    the restricted role, `session_user` stays the owner, and a policy using\n *    `current_setting('app.tenant')` filters rows correctly, including under\n *    `FORCE ROW LEVEL SECURITY`. Measured: an owner saw 3 rows and the\n *    role-switched transaction saw 2, with the cross-tenant probe returning 0.\n *    This is the one that mattered most: a dev database that quietly failed to\n *    apply RLS would give false confidence about the product's central claim.\n *\n * 4. **Concurrency is the real limit, and it fails badly.** PGlite is a single\n *    session, and `PGLiteSocketServer` multiplexes connections onto it. Two\n *    pooled clients that hold *overlapping transactions* deadlock — not error,\n *    hang — which is precisely what a request-per-transaction server does under\n *    any concurrent load. {@link MANAGED_POOL_MAX} is the answer: one client\n *    connection, so requests queue in the pool instead of deadlocking in the\n *    multiplexer. Measured: with a pool of 1, four concurrent queries and a\n *    role-switched RLS transaction all pass; with a pool of 5 the same script\n *    hangs indefinitely.\n *\n * 5. **LISTEN/NOTIFY needed repairing, and now works.** A notification is an\n *    asynchronous message with no request to answer, and the multiplexer hands\n *    it to whichever socket is reading rather than to the one that issued\n *    `LISTEN` — so a dedicated listener connection, which is exactly how the\n *    realtime engine works, received nothing while the *writer* received\n *    notifications it never asked for. `notification-proxy.ts` corrects that by\n *    copying every `NotificationResponse` frame to every client, which for a\n *    single-session database is simply the truth. Realtime therefore works\n *    against the managed database, with no change to the server: it does\n *    ordinary `LISTEN` over ordinary libpq.\n */\n\n/**\n * Extensions to hand PGlite's constructor.\n *\n * `CREATE EXTENSION` alone cannot install these — PGlite resolves them from\n * bundles supplied at construction time, so anything missing here is missing\n * from the database no matter what the migration says.\n */\nexport const PGLITE_EXTENSION_NAMES = [\"pg_trgm\", \"unaccent\"] as const;\n\n/**\n * Client connections the managed database tolerates: exactly one.\n *\n * Not a tuning choice. Two concurrent transactions over the socket\n * multiplexer deadlock, and a request-per-transaction server produces those\n * the moment two requests overlap. One connection converts that deadlock into\n * ordinary queueing, which is slower and correct.\n */\nexport const MANAGED_POOL_MAX = 1;\n\n/**\n * Connections the socket server will accept.\n *\n * Above {@link MANAGED_POOL_MAX} so that a second *non-transactional* client —\n * `rebase db push` in another terminal while `rebase dev` runs — is refused\n * with a connection error rather than corrupting the multiplexer. The pool\n * limit is what prevents overlapping transactions; this only stops a stampede.\n */\nexport const MANAGED_SERVER_MAX_CONNECTIONS = 4;\n\n/** What a managed PGlite database cannot do, in the words the user needs. */\nexport interface ManagedLimitation {\n    /** Stable id, so a warning can be suppressed or tested for. */\n    id: string;\n    /** One line, naming the feature rather than the mechanism. */\n    summary: string;\n    /** What to do instead. Always a concrete command. */\n    remedy: string;\n}\n\n/**\n * Announced at startup, every time, rather than discovered.\n *\n * A developer who does not know realtime is off will read the silence as a bug\n * in their own code, which is a worse outcome than not offering the managed\n * database at all.\n */\nexport const MANAGED_LIMITATIONS: readonly ManagedLimitation[] = [\n    {\n        id: \"concurrency\",\n        summary:\n            \"Requests are served one at a time. Behaviour is correct but serialized, so \" +\n            \"lock contention and job-queue concurrency cannot be reproduced here.\",\n        remedy: \"Reproduce concurrency against a real Postgres: rebase dev --docker\"\n    }\n] as const;\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AA+DA,IAAa,yBAAyB,CAAC,WAAW,UAAU;;;;;;;;AAuC5D,IAAa,sBAAoD,CAC7D;CACI,IAAI;CACJ,SACI;CAEJ,QAAQ;AACZ,CACJ"}