@rebasepro/cli 0.10.1-canary.6f89f77 → 0.10.1-canary.7801eed

package/dist/bundle.d.ts

@@ -0,0 +1,167 @@
+import { type NativeDependency, type RebaseBundleManifest, type RebaseBackendAppConfig } from "@rebasepro/types";
+export declare const DEFAULT_BUNDLE_DIR = "dist-bundle";
+export interface BuildBundleOptions {
+    projectRoot: string;
+    appName: string;
+    app: RebaseBackendAppConfig;
+    /** Output directory, absolute or relative to the project root. */
+    outDir?: string;
+    /** Runtime range from the manifest, recorded for compatibility checks. */
+    runtimeRange: string;
+    /** Skip type checking. Faster, and strictly worse — for iteration only. */
+    skipTypeCheck?: boolean;
+    /** Skip regenerating the Drizzle schema from the collections. */
+    skipSchema?: boolean;
+    /** Emit progress. */
+    log?: (message: string) => void;
+}
+export interface BuildBundleResult {
+    outDir: string;
+    manifest: RebaseBundleManifest;
+    collectionCount: number;
+}
+/**
+ * Whether the compiled config package exports a `storageAuthorize` hook.
+ *
+ * Recorded in the manifest so a host can refuse a deploy that would enable file
+ * storage with no access model, rather than let the runtime's boot guard turn it
+ * into a crash loop the developer cannot read.
+ *
+ * Read from the *compiled* index, deliberately: that is the exact module the
+ * runtime imports and reads the export off, so this cannot disagree with what
+ * actually happens at boot. It is a textual check rather than an import because
+ * a freshly built bundle cannot resolve its own dependencies until it is
+ * deployed — the same reason schema hashing reads source.
+ *
+ * Errs toward `false`: a missed detection costs a deploy rejection whose message
+ * says exactly how to proceed, while a false positive would hand back the crash
+ * loop this exists to prevent.
+ */
+export declare function detectStorageAuthorize(compiledConfigDir: string): boolean;
+/**
+ * Detect native code in the dependency closure.
+ *
+ * Walks declared runtime dependencies breadth-first through `node_modules`,
+ * flagging anything with a `binding.gyp`, a prebuilt `.node` binary, or an
+ * install script that builds one. The managed runtime cannot run these: a
+ * binary compiled for one image will not load in another, and finding that out
+ * at deploy time is far better than in a crash loop.
+ *
+ * The walk is bounded. A dependency graph can be enormous, and this is a
+ * heuristic gate whose false negatives are caught at deploy time anyway.
+ */
+export declare function detectNativeDependencies(projectRoot: string, declared: Record<string, string>, limit?: number): NativeDependency[];
+/**
+ * Collect the runtime dependencies a bundle needs installed beside it.
+ *
+ * Packages the runtime image already provides are excluded — reinstalling a
+ * second copy of the server next to the one running the process is at best
+ * wasted space and at worst a version conflict. Workspace packages are excluded
+ * too: they are not on the registry the runtime installs from, and the project's
+ * own config package already travels inside the bundle.
+ */
+export declare function collectDeclaredDependencies(projectRoot: string): Record<string, string>;
+/**
+ * Rewrite relative import specifiers in emitted JavaScript so Node can resolve them.
+ *
+ * TypeScript deliberately does not touch specifiers: `moduleResolution: "bundler"`
+ * lets a project write `from "./posts"` or `from "./collections"`, and TypeScript
+ * emits them unchanged on the assumption that a bundler will finish the job.
+ * Nothing bundles a Rebase bundle — the runtime imports these files directly with
+ * Node's ESM loader, which requires a full path with an extension and refuses
+ * directory imports outright.
+ *
+ * Without this, adopting the bundle would mean asking every project written in
+ * the (extremely common) extensionless style to rewrite all of its imports. The
+ * rewrite is mechanical and verifiable: only relative specifiers are touched, and
+ * only when the target file actually exists on disk.
+ */
+export declare function normalizeEsmSpecifiers(outDir: string): {
+    rewritten: number;
+    unresolved: string[];
+};
+/**
+ * A hand-written server entrypoint that a bundle does not use.
+ *
+ * `rebase dev` runs `backend/src/index.ts` whenever a project has one, so for
+ * the whole of local development that file *is* the server and every route
+ * written in it works. A bundle has no entrypoint of its own: the runtime boots
+ * the bundle and mounts what the manifest points at — the config package,
+ * functions, crons and the schema. The file is not compiled, not shipped, and
+ * never imported.
+ *
+ * Nothing said so. A project with custom routes in its entrypoint built clean,
+ * deployed green, and answered 404 on every one of them, with the file still
+ * sitting in the repository looking exactly like the server.
+ *
+ * A project that means to keep its own entrypoint declares the app as
+ * `"type": "custom"`, which builds the repository's Dockerfile instead — which
+ * is what {@link synthesizeManifest} already infers for a manifest-less repo
+ * carrying one. The warning names that route rather than implying the file is
+ * a mistake.
+ */
+export declare function findUnusedServerEntry(projectRoot: string, functionsDir: string): string | undefined;
+/**
+ * Compile and assemble a bundle.
+ */
+export declare function buildBundle(options: BuildBundleOptions): Promise<BuildBundleResult>;
+/**
+ * Package a built static app (a `static` or bundled-`admin` app) into a bundle.
+ *
+ * A static bundle is the counterpart to a backend bundle: the same shape, the
+ * same runtime image runs it, but its manifest says `mode: "static"` and it
+ * carries only the built assets under `static/`. That is what lets a frontend or
+ * admin app be its own deployable, scalable unit rather than something baked into
+ * the backend container.
+ *
+ * `assetsDir` is the app's built output (e.g. `frontend/dist`), already produced
+ * by its own build command. This copies it into the bundle and writes the
+ * manifest — no compilation, no dependency closure (a static bundle installs
+ * nothing at boot).
+ */
+/**
+ * Fold a built static app into a backend bundle, so one runtime serves both.
+ *
+ * ## Why this exists
+ *
+ * A managed tenant runs one pod, and `bootFromBundle` on the backend path already
+ * knows how to serve a SPA — it looks for `entry.static` and mounts `serveSPA`
+ * last, behind `REBASE_SERVE_STATIC`. What was missing was anything putting the
+ * assets there.
+ *
+ * The consequence was not subtle. A project whose custom image served its website
+ * at `/` and its API at `/api` — the shape the scaffolded template produces — lost
+ * the website the moment it moved to the managed runtime: the API answered
+ * perfectly and every page 404'd. Managed could not be a drop-in replacement for
+ * custom while the frontend simply vanished.
+ *
+ * Folding restores parity with the container it replaces, which is the only
+ * honest baseline. It is deliberately the FIRST implementation and not the last:
+ * a static app on its own bucket behind a CDN is better for cache behaviour and
+ * lets the frontend deploy independently. But that needs infrastructure that does
+ * not exist yet, and "your site is gone" is not an acceptable state to leave a
+ * project in while it gets built.
+ *
+ * The trade it makes, stated plainly: frontend and backend now deploy together
+ * and the bundle carries the built assets. For a project that was shipping both
+ * in one image already, that is exactly what it had.
+ */
+export declare function foldStaticIntoBundle(options: {
+    /** The backend bundle directory, already written. */
+    bundleDir: string;
+    /** Directory of built frontend assets (the static app's `output`). */
+    assetsDir: string;
+}): {
+    fileCount: number;
+};
+export declare function buildStaticBundle(options: {
+    projectRoot: string;
+    appName: string;
+    assetsDir: string;
+    outDir: string;
+    runtimeRange: string;
+}): {
+    outDir: string;
+    manifest: RebaseBundleManifest;
+    fileCount: number;
+};

package/dist/commands/apps.d.ts

@@ -0,0 +1 @@
+export declare function appsCommand(subcommand: string | undefined, rawArgs?: string[]): Promise<void>;

package/dist/commands/build.d.ts

@@ -1 +1 @@
-export declare function buildCommand(): Promise<void>;
+export declare function buildCommand(rawArgs?: string[]): Promise<void>;

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

@@ -0,0 +1,53 @@
+import type { RebaseBundleManifest } from "@rebasepro/types";
+/** Read and shallow-validate a built bundle's manifest. */
+export declare function readBundleManifest(bundleDir: string): RebaseBundleManifest;
+/**
+ * Tar a built bundle into a gzipped archive.
+ *
+ * `node_modules` is excluded on purpose: the bundle ships a `package.json`, and
+ * the managed runtime installs the declared dependencies at boot. Uploading an
+ * installed `node_modules` would bloat the archive and could carry a
+ * platform-specific build that will not run on the runtime image.
+ */
+export declare function packBundle(bundleDir: string, outPath: string): Promise<void>;
+/**
+ * Assemble the deploy-trigger body for a bundle deploy.
+ *
+ * The manifest travels with the trigger so the control plane can validate intake
+ * without unpacking the uploaded archive first — a rejection (native deps, no
+ * matching runtime) is then a fast, cheap answer.
+ */
+export declare function bundleDeployBody(input: {
+    projectId: string;
+    bundleId: string;
+    manifest: RebaseBundleManifest;
+    app?: string;
+    message?: string;
+    /**
+     * Every app this repository declares in `rebase.json`, so the platform can
+     * register the whole set rather than only the one being deployed.
+     */
+    declaredApps?: DeclaredApp[];
+}): Record<string, unknown>;
+/** An app as `rebase.json` declares it, reduced to what the registry stores. */
+export interface DeclaredApp {
+    name: string;
+    type: string;
+}
+/**
+ * The apps a project manifest declares.
+ *
+ * A deploy only ever ships ONE app's bundle, so the trigger alone could never
+ * tell the platform that the repository also contains a web frontend and an
+ * admin panel — and the Apps page, whose whole job is to show the set, listed a
+ * single entry called "backend". Sending the declared set fixes that without
+ * pretending the others are deployed: the platform registers them, and their
+ * status says what is actually true.
+ */
+export declare function declaredAppsFrom(manifest: {
+    apps?: Record<string, {
+        type?: string;
+    }>;
+} | null | undefined): DeclaredApp[];
+/** Upload a bundle archive; returns the control-plane bundle id. */
+export declare function uploadBundle(url: string, token: string, projectId: string, tarPath: string): Promise<string>;

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

@@ -62,6 +62,24 @@ export interface ProjectLink {
     slug?: string;
     projectName?: string;
     orgId?: string;
+    /**
+     * Base URL of the project's own API.
+     *
+     * For a cloud project this is a convenience derived from the subdomain. For
+     * a **self-hosted** project it is the entire link: there is no control plane
+     * to look anything up in, so `projectId` is empty and this is what commands
+     * resolve against.
+     *
+     * Keeping both kinds of link in one file is deliberate. A second link file
+     * for self-hosting would fork every command that reads one, and the tooling
+     * would drift into being cloud-only by accident.
+     */
+    apiUrl?: string;
+    /**
+     * How this checkout is linked. Absent means `cloud` — which is every link
+     * written before this field existed.
+     */
+    mode?: "cloud" | "direct";
 }
 export declare function readLink(cwd?: string): ProjectLink | null;
 export declare function writeLink(link: ProjectLink, cwd?: string): void;

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

@@ -1,2 +1,50 @@
+/** A project row, reduced to what says how it deploys (camel or snake columns). */
+export interface DeployProjectRow {
+    runtimeMode?: string;
+    runtime_mode?: string;
+    gitRepoUrl?: string;
+    git_repo_url?: string;
+    gitBranch?: string;
+    git_branch?: string;
+}
+/** A deployment row, reduced to what says what it was built from. */
+export interface DeploySourceRow {
+    id?: string | number;
+    status?: string;
+    createdAt?: string | Date;
+    created_at?: string | Date;
+    sourceRef?: string;
+    source_ref?: string;
+    bundleId?: string;
+    bundle_id?: string;
+}
+export interface BareDeployPlan {
+    /**
+     * Whether the project runs the platform runtime — in which case any source
+     * build here ejects it back onto a container image.
+     */
+    managed: boolean;
+    /**
+     * `git` — the control plane will clone the configured repository.
+     * `snapshot` — it will rebuild the newest uploaded source archive.
+     * `none` — it holds neither, and will refuse.
+     */
+    source: "git" | "snapshot" | "none";
+    /** Lines describing the build, printed before it is triggered. */
+    lines: string[];
+}
+/** Rough age of a timestamp, for "…uploaded 6d ago". Undefined if unreadable. */
+export declare function timeAgo(value: string | Date | undefined, now: Date): string | undefined;
+/**
+ * Whether this project runs on the managed runtime.
+ *
+ * `runtimeMode` on the project row is the authority — the control plane writes
+ * it. The bundle-id fallback covers a control plane that does not return the
+ * field: a successful deploy that served a bundle only happens on the managed
+ * path.
+ */
+export declare function isManagedProject(project: DeployProjectRow | undefined, latest: DeploySourceRow | undefined): boolean;
+/** What a `deploy` with nothing attached will build, in the words to print. */
+export declare function planBareDeploy(project: DeployProjectRow | undefined, latest: DeploySourceRow | undefined, now: Date): BareDeployPlan;
 export declare function deployCommand(rawArgs: string[], projectRef: string): Promise<void>;
 export declare function logsCommand(rawArgs: string[], projectRef: string): Promise<void>;

package/dist/commands/generate_sdk.d.ts

@@ -10,7 +10,32 @@ interface GenerateSDKArgs {
     collectionsDir: string;
     output: string;
     cwd: string;
+    /**
+     * Where to read the schema from instead of local source.
+     *
+     * `link` uses this checkout's linked project; anything else is treated as
+     * the base URL of a Rebase backend. This is what lets a repository that
+     * contains no collections — a separate frontend, a second web app — generate
+     * a typed client from the project it talks to.
+     */
+    from?: string;
+    /** Bearer token for the contract endpoint. Falls back to REBASE_SERVICE_KEY. */
+    token?: string;
+    help?: boolean;
 }
+/**
+ * The base URL to show in the printed usage example.
+ *
+ * `rebase dev` binds a port derived from the project path, not 3001, and writes
+ * the one it actually got to `.rebase/state.json`. Printing a hardcoded
+ * `localhost:3001` sent people to a port nothing was listening on — or, with
+ * several projects on one machine, to a different project's backend. Prefer the
+ * port this project last ran on; fall back to the literal only when the project
+ * has never been started.
+ */
+export declare function resolveExampleBaseUrl(cwd: string): string;
+/** Whether a slug can be written as `rebase.data.<slug>` rather than a lookup. */
+export declare function isIdentifierLike(slug: string): boolean;
 /**
  * Main entry point for the generate-sdk command.
  */

package/dist/commands/start.d.ts

@@ -1 +1 @@
-export declare function startCommand(): Promise<void>;
+export declare function startCommand(rawArgs?: string[]): Promise<void>;

package/dist/fold-static.d.ts

@@ -0,0 +1,46 @@
+/** The apps section of a project manifest, as much of it as folding needs. */
+export interface FoldableManifest {
+    apps?: Record<string, {
+        type?: string;
+        build?: string;
+        output?: string;
+    }>;
+}
+export interface FoldOptions {
+    projectRoot: string;
+    manifest: FoldableManifest;
+    /** The backend bundle directory, already written. */
+    bundleDir: string;
+    /** Skip running the app's own build command; fold what is already built. */
+    skipBuild?: boolean;
+    log?: (message: string) => void;
+}
+export interface FoldOutcome {
+    appName: string;
+    fileCount: number;
+}
+/**
+ * Which static app, if any, should be served by the backend.
+ *
+ * Exactly one `static` app is folded. With several, folding would have to choose,
+ * and silently picking one of two websites is worse than doing nothing — so it
+ * declines and names what it saw. Pure, so the decision is testable without a
+ * filesystem.
+ */
+export declare function selectFoldableApp(manifest: FoldableManifest): {
+    app?: {
+        name: string;
+        build?: string;
+        output?: string;
+    };
+    /** Why nothing will be folded, when that is the answer. */
+    reason?: string;
+};
+/**
+ * Build the project's frontend and fold it into the backend bundle.
+ *
+ * Throws rather than exiting, so the caller decides whether a missing frontend
+ * should fail its command — a `build` may reasonably want to stop, and so should
+ * a deploy, but that is not this function's call to make.
+ */
+export declare function foldFrontendIntoBundle(options: FoldOptions): Promise<FoldOutcome | null>;

package/dist/index.d.ts

@@ -9,5 +9,8 @@ export * from "./commands/auth";
 export * from "./commands/doctor";
 export * from "./commands/generate_sdk";
 export * from "./commands/cloud";
+export * from "./commands/apps";
 export * from "./utils/project";
 export * from "./utils/package-manager";
+export * from "./manifest";
+export * from "./bundle";