@valbuild/server 0.136.0 → 0.136.2

package/CHANGELOG.md

@@ -1,5 +1,42 @@
 # @valbuild/server
 
+## 0.136.2
+
+### Patch Changes
+
+- [#720](https://github.com/valbuild/val/pull/720) [`f76cd56`](https://github.com/valbuild/val/commit/f76cd56b9f1c1bcc0a608a7a4de24b1e776adccb) Thanks [@freekh](https://github.com/freekh)! - A managed project published from the Studio keeps its images, and a project created from a template can publish from the Studio at all.
+
+  - A publish from the Studio carries over every file under `public/` that the site already serves, so the favicon and images no longer disappear after the first Studio publish. When content published the live build, it already holds those files and nothing is uploaded again. When it didn't (a project cloned from a template), the Studio reads them from the site it runs on and builds with them.
+  - An image uploaded in the Studio is now part of the build that publishes it. For a managed project, `/save` returns the files the commit wrote (`binaryFiles`), the same way it already returns the `.val.ts` text.
+  - `/save` also returns the project's branch for a managed project, and the Studio's build uses it. A project cloned from a template was wired at no commit and no branch, so its first Studio publish went out branchless and the platform refused it.
+  - When neither content nor the platform can say which public files the live site serves, the Studio refuses to publish and says so, rather than publishing a site without them.
+
+- Updated dependencies [[`f76cd56`](https://github.com/valbuild/val/commit/f76cd56b9f1c1bcc0a608a7a4de24b1e776adccb)]:
+  - @valbuild/ui@0.136.2
+  - @valbuild/shared@0.136.2
+
+## 0.136.1
+
+### Patch Changes
+
+- [#716](https://github.com/valbuild/val/pull/716) [`4450be5`](https://github.com/valbuild/val/commit/4450be570ec3a66d7d98ba273c333ca2d2f163d9) Thanks [@freekh](https://github.com/freekh)! - `rebakeGit` rewires a project record to a different commit, and the Studio's publish proxy can now reach `/project-source`.
+
+  Both are groundwork for a publish that happens in the browser. `rebakeGit` replaces the one line in the generated `val.server.ts` that carries the commit, rather than regenerating the file: a publisher running inside the deployment does not know the project id or the platform's address, and reconstructing the file from what it could guess would throw away wiring it cannot see.
+
+- [#716](https://github.com/valbuild/val/pull/716) [`d2f385a`](https://github.com/valbuild/val/commit/d2f385a04978992a5036379235e447ba7775faef) Thanks [@freekh](https://github.com/freekh)! - The Studio works again when served from the published package, and a managed project's publish now puts the saved edit on the site.
+
+  - **The Studio did not start in 0.136.0.** Its main bundle imports sibling chunks by relative path, and the Studio is served at `/api/val/static/<version>/app`, so those imports resolved to paths the handler did not know and came back as the HTML fallback — which a browser refuses as a module script. Preview was gone with it. The handler now serves those chunks, and the package build follows every import the bundle makes before it lets a release through.
+  - **The in-browser builder could not load.** The Studio's bundle carried rolldown's Node WASI binding, which throws `process is not defined` in a tab. It now uses the browser binding, and the build refuses a bundle that contains the Node one.
+  - **A managed publish builds what was just saved.** `/save` returns the source files the commit wrote, the Studio builds with them laid over the project's stored source, and publishes that source back with the build — so the next edit starts from this one rather than undoing it. The save's commit is also passed through to the build, which previously ran as though no commit had been made.
+  - **The bundler's WebAssembly is served from `content.val.build/v1/static`** (`DEFAULT_STATIC_HOST`), still addressed by its SHA-256. `globalThis.__VAL_ROLLDOWN_WASM_URL__` still overrides it.
+  - The `val.server.ts` that `@valbuild/tanstack-build` generates no longer hands a save's files to the platform (`platform.internal/__api/source`). A managed project's Studio builds in its own tab, and the platform has closed that door. `isWired` recognises files wired either way.
+  - `@valbuild/tanstack-build/constants` exports the contract paths and the artifact key namespace from an entrypoint that imports nothing else, for callers that must not load the bundler. The namespace gains a `source` key.
+
+- Updated dependencies [[`cf89e74`](https://github.com/valbuild/val/commit/cf89e7429a79c4304ecbedd4f8b571a0de0f145f), [`c219574`](https://github.com/valbuild/val/commit/c21957498f3c7f4f47cef197c5dc0d591aa744ca), [`e673b43`](https://github.com/valbuild/val/commit/e673b43feaf48b7f30881d6786c858a0cb6a44a2), [`5c82928`](https://github.com/valbuild/val/commit/5c82928992d29f133f81cf0704a273c0449b18f1), [`d2f385a`](https://github.com/valbuild/val/commit/d2f385a04978992a5036379235e447ba7775faef)]:
+  - @valbuild/ui@0.136.1
+  - @valbuild/shared@0.136.1
+  - @valbuild/core@0.136.1
+
 ## 0.136.0
 
 ### Minor Changes

package/dist/declarations/src/ValOps.d.ts

@@ -433,6 +433,43 @@ export declare abstract class ValOps {
      * an older service.
      */
     sourceMode(): "managed" | "connected" | null;
+    /**
+     * The branch the content service keeps this project's commits on, or `null`
+     * where there is no such service, or it has not said yet.
+     *
+     * For the Studio's in-tab build of a managed project, which has to name the
+     * branch its build was made at. Its other source is the `val.server.ts` the
+     * last build was wired with -- and a project cloned from a template seed has
+     * one wired at NO commit and no branch, so its first publish went out
+     * branchless and the loader refused it for a project whose pointer follows a
+     * branch. This is the project's own word for it.
+     */
+    projectBranch(): string | null;
+    /**
+     * Forward one call to the content service's publish API, as this project.
+     *
+     * The Studio builds a managed project in the tab and then has to publish what
+     * it built -- but a browser cannot talk to content directly. It holds a
+     * session cookie for THIS origin and no credential content would accept, so
+     * the conversation goes through here, exactly as patches already do.
+     *
+     * Refused by default, and that is the honest answer rather than a gap: `fs`
+     * and memory mode have no content service to forward to, and publishing there
+     * is writing to disk.
+     *
+     * The path is content's, minus the `/v1` prefix -- `/publish`,
+     * `/publish/{id}/artifacts`, `/build-target`. The ALLOW LIST lives in the
+     * implementation rather than here, because it is what keeps this from being
+     * a way to reach the rest of content with the project's credential.
+     */
+    publishApi(_path: string, _init: {
+        method: string;
+        body?: string;
+    }): Promise<{
+        status: number;
+        body: string;
+        contentType: string;
+    }>;
     /**
      * Whether a commit here produces `.val.ts` TEXT as well as data.
      *

package/dist/declarations/src/ValOpsHttp.d.ts

@@ -141,6 +141,69 @@ export declare class ValOpsHttp extends ValOps {
      * has just arrived.
      */
     sourceMode(): "managed" | "connected" | null;
+    /** Remembered with {@link sourceMode}, from the same response. */
+    projectBranch(): string | null;
+    /**
+     * The short-lived publish token, and when it stops being usable.
+     *
+     * `null` until something publishes, which for most deployments is never.
+     */
+    private publishToken;
+    /**
+     * Trade this deployment's credential for one that can do one thing.
+     *
+     * Content's publish API takes a PROJECT TOKEN and nothing else --
+     * `authenticateProjectToken` refuses anything that is not one, deliberately,
+     * because a personal access token is a person's credential and does not name
+     * a project. What this deployment holds is the project's api key, which is
+     * neither.
+     *
+     * `POST /v1/{org}/{project}/publish-token` is the exchange, and it was built
+     * for exactly this: its own docblock names the case where "the caller was the
+     * project's api key ... a machine exchanging one machine credential for a
+     * narrower one". What comes back can publish one project for ten minutes.
+     *
+     * So the api key never leaves this process and the browser never sees any
+     * credential at all. That is the point of routing the publish through here
+     * rather than letting the tab talk to content.
+     */
+    private mintPublishToken;
+    /**
+     * A usable publish token, minting one when what we have will not last.
+     *
+     * The margin is what stops a token that is valid when the publish starts from
+     * expiring in the middle of it: a publish is five calls and an upload of
+     * every artifact, and the upload is the slow one.
+     */
+    private currentPublishToken;
+    /**
+     * The content paths this may reach, and nothing else.
+     *
+     * An allow list rather than a prefix check, because this method holds a
+     * credential and the browser chooses the path. `/publish/{id}` and its three
+     * steps are the publish conversation; `/build-target` is what a build needs
+     * to know before it starts; `/project-source` is what it builds.
+     *
+     * `/project-source` is here rather than on a route of its own because it is
+     * one of the three things a publish asks for and none of them are useful
+     * apart -- and because the credential is the same one. The Studio cannot get
+     * the project's files any other way: it runs inside the deployment, which
+     * holds a session for its own origin and an api key for content, and content
+     * is the only thing it is allowed to talk to at all.
+     *
+     * A publish id is opaque and content-generated, so it is matched rather than
+     * parsed -- what matters is that nothing with a `..`, a query or another
+     * segment gets through.
+     */
+    private static publishApiPathAllowed;
+    publishApi(path: string, init: {
+        method: string;
+        body?: string;
+    }): Promise<{
+        status: number;
+        body: string;
+        contentType: string;
+    }>;
     onInit(): Promise<void>;
     getPresignedAuthNonce(profileId: string, corsOrigin: string): Promise<{
         status: "success";

package/dist/valbuild-server.cjs.dev.js

@@ -4595,6 +4595,48 @@ class ValOps {
     return null;
   }
 
+  /**
+   * The branch the content service keeps this project's commits on, or `null`
+   * where there is no such service, or it has not said yet.
+   *
+   * For the Studio's in-tab build of a managed project, which has to name the
+   * branch its build was made at. Its other source is the `val.server.ts` the
+   * last build was wired with -- and a project cloned from a template seed has
+   * one wired at NO commit and no branch, so its first publish went out
+   * branchless and the loader refused it for a project whose pointer follows a
+   * branch. This is the project's own word for it.
+   */
+  projectBranch() {
+    return null;
+  }
+
+  /**
+   * Forward one call to the content service's publish API, as this project.
+   *
+   * The Studio builds a managed project in the tab and then has to publish what
+   * it built -- but a browser cannot talk to content directly. It holds a
+   * session cookie for THIS origin and no credential content would accept, so
+   * the conversation goes through here, exactly as patches already do.
+   *
+   * Refused by default, and that is the honest answer rather than a gap: `fs`
+   * and memory mode have no content service to forward to, and publishing there
+   * is writing to disk.
+   *
+   * The path is content's, minus the `/v1` prefix -- `/publish`,
+   * `/publish/{id}/artifacts`, `/build-target`. The ALLOW LIST lives in the
+   * implementation rather than here, because it is what keeps this from being
+   * a way to reach the rest of content with the project's credential.
+   */
+  async publishApi(_path, _init) {
+    return {
+      status: 501,
+      contentType: "application/json",
+      body: JSON.stringify({
+        message: "This Val server has no content service to publish through. " + "Publishing from the browser is for a project whose content is " + "served over HTTP."
+      })
+    };
+  }
+
   /**
    * Whether a commit here produces `.val.ts` TEXT as well as data.
    *
@@ -7492,6 +7534,42 @@ class FSOpsHost {
   }
 }
 
+/**
+ * The bytes of the local binary files a commit is about to write, base64.
+ *
+ * For the Studio's in-tab build of a managed project, which publishes the site:
+ * an image uploaded in this save is in no earlier build, so unless the build
+ * is given it the published page links a file that 404s. Remote files are left
+ * out -- they are served from their own URL and never were part of a build.
+ *
+ * A file that cannot be read is NAMED rather than dropped, and does not stop
+ * the save: the commit is what makes an edit durable, and the build is the
+ * step that can refuse.
+ *
+ * Read BEFORE the commit, because after it the files are no longer the
+ * patch's to read. Generic over the patch id so it asks for exactly the one
+ * method it uses, and a test can hand it a plain object.
+ */
+async function readCommittedBinaryFiles(ops, descriptors) {
+  const files = {};
+  const unread = [];
+  await Promise.all(Object.entries(descriptors).map(async ([filePath, {
+    patchId,
+    remote
+  }]) => {
+    if (remote) return;
+    const bytes = await ops.getBase64EncodedBinaryFileFromPatch(filePath, patchId, remote).catch(error => {
+      console.error("Could not read a committed file", filePath, error);
+      return null;
+    });
+    if (bytes === null) unread.push(filePath);else files[filePath] = bytes.toString("base64");
+  }));
+  return {
+    files,
+    unread: unread.sort()
+  };
+}
+
 /**
  * Which unpublished changes a failed save has to throw away to make progress.
  *
@@ -7973,6 +8051,189 @@ class ValOpsHttp extends ValOps {
     var _this$projectExpectat2;
     return ((_this$projectExpectat2 = this.projectExpectation) === null || _this$projectExpectat2 === void 0 ? void 0 : _this$projectExpectat2.sourceMode) ?? null;
   }
+
+  /** Remembered with {@link sourceMode}, from the same response. */
+  projectBranch() {
+    var _this$projectExpectat3;
+    return ((_this$projectExpectat3 = this.projectExpectation) === null || _this$projectExpectat3 === void 0 ? void 0 : _this$projectExpectat3.branch) ?? null;
+  }
+
+  /**
+   * The short-lived publish token, and when it stops being usable.
+   *
+   * `null` until something publishes, which for most deployments is never.
+   */
+  publishToken = null;
+
+  /**
+   * Trade this deployment's credential for one that can do one thing.
+   *
+   * Content's publish API takes a PROJECT TOKEN and nothing else --
+   * `authenticateProjectToken` refuses anything that is not one, deliberately,
+   * because a personal access token is a person's credential and does not name
+   * a project. What this deployment holds is the project's api key, which is
+   * neither.
+   *
+   * `POST /v1/{org}/{project}/publish-token` is the exchange, and it was built
+   * for exactly this: its own docblock names the case where "the caller was the
+   * project's api key ... a machine exchanging one machine credential for a
+   * narrower one". What comes back can publish one project for ten minutes.
+   *
+   * So the api key never leaves this process and the browser never sees any
+   * credential at all. That is the point of routing the publish through here
+   * rather than letting the tab talk to content.
+   */
+  async mintPublishToken() {
+    const res = await fetch(`${this.contentUrl}/v1/${this.project}/publish-token`, {
+      method: "POST",
+      headers: this.authHeaders
+    });
+    const text = await res.text();
+    if (!res.ok) {
+      return {
+        status: res.status,
+        error: `Could not get a publish token for '${this.project}': ` + `${res.status} ${text.slice(0, 300)}`
+      };
+    }
+    let parsed;
+    try {
+      parsed = JSON.parse(text);
+    } catch {
+      return {
+        status: 502,
+        error: "The publish token exchange did not answer with JSON."
+      };
+    }
+    const token = typeof parsed === "object" && parsed !== null && "token" in parsed && typeof parsed.token === "string" ? parsed.token : null;
+    if (token === null) {
+      return {
+        status: 502,
+        error: "The publish token exchange sent no token."
+      };
+    }
+    const expiresAtRaw = typeof parsed === "object" && parsed !== null && "expiresAt" in parsed ? parsed.expiresAt : null;
+    const expiresAt = typeof expiresAtRaw === "string" ? Date.parse(expiresAtRaw) : NaN;
+    return {
+      token,
+      /*
+       * A token with no expiry, or one we cannot read, is treated as expiring
+       * NOW -- so it is used for this call and minted again for the next.
+       * Caching one we cannot reason about is how a publish starts failing
+       * halfway through, days later, for no reason anyone can see.
+       */
+      expiresAt: Number.isFinite(expiresAt) ? expiresAt : 0
+    };
+  }
+
+  /**
+   * A usable publish token, minting one when what we have will not last.
+   *
+   * The margin is what stops a token that is valid when the publish starts from
+   * expiring in the middle of it: a publish is five calls and an upload of
+   * every artifact, and the upload is the slow one.
+   */
+  async currentPublishToken() {
+    const margin = 60_000;
+    if (this.publishToken !== null && this.publishToken.expiresAt - margin > Date.now()) {
+      return {
+        token: this.publishToken.token
+      };
+    }
+    const minted = await this.mintPublishToken();
+    if ("error" in minted) {
+      this.publishToken = null;
+      return minted;
+    }
+    this.publishToken = minted;
+    return {
+      token: minted.token
+    };
+  }
+
+  /**
+   * The content paths this may reach, and nothing else.
+   *
+   * An allow list rather than a prefix check, because this method holds a
+   * credential and the browser chooses the path. `/publish/{id}` and its three
+   * steps are the publish conversation; `/build-target` is what a build needs
+   * to know before it starts; `/project-source` is what it builds.
+   *
+   * `/project-source` is here rather than on a route of its own because it is
+   * one of the three things a publish asks for and none of them are useful
+   * apart -- and because the credential is the same one. The Studio cannot get
+   * the project's files any other way: it runs inside the deployment, which
+   * holds a session for its own origin and an api key for content, and content
+   * is the only thing it is allowed to talk to at all.
+   *
+   * A publish id is opaque and content-generated, so it is matched rather than
+   * parsed -- what matters is that nothing with a `..`, a query or another
+   * segment gets through.
+   */
+  static publishApiPathAllowed(path) {
+    if (path === "/build-target" || path === "/project-source" || path === "/publish") {
+      return true;
+    }
+    return /^\/publish\/[A-Za-z0-9_-]+(\/(artifacts|verify|promote))?$/.test(path);
+  }
+  async publishApi(path, init) {
+    const json = "application/json";
+    if (!ValOpsHttp.publishApiPathAllowed(path)) {
+      return {
+        status: 403,
+        contentType: json,
+        body: JSON.stringify({
+          message: `'${path}' is not part of the publish API.`
+        })
+      };
+    }
+    const send = async token => fetch(`${this.contentUrl}/v1${path}`, {
+      method: init.method,
+      headers: {
+        Authorization: `Bearer ${token}`,
+        ...(init.body === undefined ? {} : {
+          "Content-Type": json
+        })
+      },
+      ...(init.body === undefined ? {} : {
+        body: init.body
+      })
+    });
+    const credential = await this.currentPublishToken();
+    if ("error" in credential) {
+      return {
+        status: credential.status,
+        contentType: json,
+        body: JSON.stringify({
+          message: credential.error
+        })
+      };
+    }
+    let res = await send(credential.token);
+    if (res.status === 401) {
+      /*
+       * Revoked, or expired sooner than it said. One retry with a fresh token,
+       * because the alternative is a publish that fails for a reason the editor
+       * cannot act on and a retry that fails the same way.
+       */
+      this.publishToken = null;
+      const second = await this.currentPublishToken();
+      if ("error" in second) {
+        return {
+          status: second.status,
+          contentType: json,
+          body: JSON.stringify({
+            message: second.error
+          })
+        };
+      }
+      res = await send(second.token);
+    }
+    return {
+      status: res.status,
+      contentType: res.headers.get("content-type") ?? json,
+      body: await res.text()
+    };
+  }
   async onInit() {
     // TODO: unused for now. Implement or remove
   }
@@ -11531,6 +11792,38 @@ const ValServer = (valModules, options, callbacks) => {
       }
     };
   };
+
+  /**
+   * Hand one publish-API call to content and carry the answer back.
+   *
+   * `JSON.parse` and nothing more. That is not validation -- there is no schema
+   * here and no knowledge of content's shapes -- it is the round trip a JSON
+   * body has to make to travel as `json` rather than as a string. A body that
+   * does not parse is a gateway's error page rather than content answering, so
+   * it comes back as a message with the original status instead of throwing:
+   * a publish that failed is something the editor has to be told in words.
+   */
+  const proxyPublishApi = async (path, method, body) => {
+    const answer = await serverOps.publishApi(path ?? "", {
+      method,
+      ...(body === undefined ? {} : {
+        body
+      })
+    });
+    try {
+      return {
+        status: answer.status,
+        json: JSON.parse(answer.body)
+      };
+    } catch {
+      return {
+        status: answer.status,
+        json: {
+          message: answer.body.trim() === "" ? `The publish API answered ${answer.status} with no body.` : `The publish API answered ${answer.status}: ${answer.body.slice(0, 300)}`
+        }
+      };
+    }
+  };
   return {
     "/draft/enable": {
       GET: async req => {
@@ -11981,6 +12274,47 @@ const ValServer = (valModules, options, callbacks) => {
         };
       }
     },
+    /**
+     * The content service's publish API, reached through this deployment.
+     *
+     * The Studio builds a managed project in its own tab and then publishes
+     * what it built. It cannot talk to content directly -- it holds a session
+     * cookie for this origin and no credential content would accept -- so the
+     * whole conversation comes through here.
+     *
+     * Three things happen, and nothing else: the session is checked, the
+     * credential is swapped for a publish-scoped one (see
+     * `ValOpsHttp.publishApi`), and content's answer is carried back with its
+     * status intact. The Studio parses that answer with the same module
+     * `val publish` uses, so there is no copy of content's shapes here to
+     * fall out of step.
+     */
+    "/publish-api": {
+      GET: async req => {
+        const auth = getAuth(req.cookies);
+        if (auth.error) {
+          return {
+            status: 401,
+            json: {
+              message: auth.error
+            }
+          };
+        }
+        return proxyPublishApi(req.path, "GET");
+      },
+      POST: async req => {
+        const auth = getAuth(req.cookies);
+        if (auth.error) {
+          return {
+            status: 401,
+            json: {
+              message: auth.error
+            }
+          };
+        }
+        return proxyPublishApi(req.path, "POST", req.body === undefined ? undefined : JSON.stringify(req.body));
+      }
+    },
     "/upload/patches": {
       POST: async req => {
         if (serverOps instanceof ValOpsHttp) {
@@ -13480,6 +13814,12 @@ const ValServer = (valModules, options, callbacks) => {
               }
             }
             const message = body.message || "Val CMS update (" + Object.keys(analysis.patchesByModule).length + " files changed)";
+            /*
+             * Before the commit, because after it the files are no longer the
+             * patch's to read. See `binaryFiles` on the route.
+             */
+            const managedBranch = serverOps.sourceMode() === "managed" ? serverOps.projectBranch() : null;
+            const committedBinaries = serverOps.sourceMode() === "managed" ? await readCommittedBinaryFiles(serverOps, preparedCommit.patchedBinaryFilesDescriptors) : null;
             const commitToGit = () => {
               var _options$config$files;
               return serverOps.commit(preparedCommit, message, auth.id, ((_options$config$files = options.config.files) === null || _options$config$files === void 0 ? void 0 : _options$config$files.directory) || "/public/val", undefined,
@@ -13538,7 +13878,24 @@ const ValServer = (valModules, options, callbacks) => {
             return {
               status: 200,
               json: {
-                commitSha: commitRes.commit
+                commitSha: commitRes.commit,
+                /*
+                 * For the Studio to BUILD, when it is the deployer. See
+                 * `sourceFiles` on the route: the build must contain the text
+                 * this commit wrote, and only this handler has it.
+                 */
+                ...(serverOps.sourceMode() === "managed" ? {
+                  sourceFiles: preparedCommit.patchedSourceFiles
+                } : {}),
+                ...(managedBranch !== null ? {
+                  branch: managedBranch
+                } : {}),
+                ...(committedBinaries !== null ? {
+                  binaryFiles: committedBinaries.files,
+                  ...(committedBinaries.unread.length > 0 ? {
+                    binaryFilesUnread: committedBinaries.unread
+                  } : {})
+                } : {})
               }
             };
           }