@valbuild/shared 0.134.0 → 0.136.0

package/CHANGELOG.md

@@ -1,5 +1,77 @@
 # @valbuild/shared
 
+## 0.136.0
+
+### Minor Changes
+
+- [#713](https://github.com/valbuild/val/pull/713) [`f3a4bb7`](https://github.com/valbuild/val/commit/f3a4bb7aea604943b92545c122243798c759715c) Thanks [@freekh](https://github.com/freekh)! - The Studio can load a bundler, and it stops telling a managed project that its
+  publish is on its way out.
+
+  **A managed project is one with no repository and no host watching one.** There
+  is nothing outside the browser to pick a commit up, so the Studio has been
+  showing it a story that belongs to a project with a repository: a `Building`
+  spinner, waiting for an event that can never arrive. It does not resolve on a
+  reload, on a retry, or tomorrow, and there is no way to tell it from a deploy
+  that is merely slow.
+
+  The content service now reports which kind of project this is, as `sourceMode`
+  on `/stat`, and the Studio narrates accordingly:
+
+  - a **connected** project keeps the deploy feed and keeps `Building`, because
+    there a host genuinely does pick the commit up;
+  - a **managed** one says `Saved, not yet live` instead — a durable condition,
+    not a phase, because nothing else will ever resolve it.
+
+  A server that reports no source mode keeps the behaviour it has today. Absence
+  means "not reported", never "managed": `fs` mode has no project to have a mode,
+  and neither does a content service that predates the field.
+
+  **The Studio also loads `@valbuild/tanstack-build` in the tab**, at mount and at
+  idle, for the managed projects that will need it — a browser that is the
+  deployer needs a bundler. This is the groundwork for browser-side publishing;
+  the publish path itself is unchanged in this release.
+
+  That bundler is `@rolldown/browser`, whose WebAssembly binary is 10.9 MB and is
+  **not** in the npm package. It is served from `static.val.build`, addressed by
+  the SHA-256 of its own bytes, so the build and the binary it needs cannot drift
+  apart. A deployment that must not reach that host — an air-gapped install, a
+  mirror — sets `globalThis.__VAL_ROLLDOWN_WASM_URL__` before the Studio loads and
+  needs no rebuild.
+
+  **Building in the browser requires a cross-origin isolated page.** Rolldown runs
+  WebAssembly on worker threads that share memory, and a browser will not hand a
+  `SharedArrayBuffer` to a worker otherwise. Without
+  `Cross-Origin-Opener-Policy: same-origin` and
+  `Cross-Origin-Embedder-Policy: require-corp` on the document Val is mounted in,
+  loading the bundler now fails with a message that says exactly that, instead of
+  a `DataCloneError` thrown from inside a worker. Nothing else in this release is
+  affected: a Studio that never builds in the browser never asks.
+
+### Patch Changes
+
+- Updated dependencies [[`f3a4bb7`](https://github.com/valbuild/val/commit/f3a4bb7aea604943b92545c122243798c759715c)]:
+  - @valbuild/core@0.136.0
+
+## 0.134.1
+
+### Patch Changes
+
+- [#709](https://github.com/valbuild/val/pull/709) [`821e789`](https://github.com/valbuild/val/commit/821e789c1af47510af5d23eb96384ff78ddd7646) Thanks [@freekh](https://github.com/freekh)! - Show the reason behind a content-service error instead of just "Internal Server
+  Error".
+
+  `content.val.build` answers a handler that threw with `{ message: "Internal
+Server Error", details: "<the actual cause>" }`. Val was reading `message` and
+  dropping `details`, so a failed save put exactly this in front of an editor —
+  and the same text in the app's own logs, because Val was relaying it:
+
+  ```json
+  { "type": "patch-error", "message": "Internal Server Error", "errors": { … } }
+  ```
+
+  A string `details` is now appended to the message (capped at 500 characters).
+  A structured one is not: that is what a _refusal_ carries, and its summary is
+  already the message.
+
 ## 0.134.0
 
 ### Minor Changes

package/dist/declarations/src/internal/ApiRoutes.d.ts

@@ -423,6 +423,7 @@ export declare const Api: {
                     profileId: z.ZodNullable<z.ZodString>;
                     mode: z.ZodUnion<readonly [z.ZodLiteral<"http">, z.ZodLiteral<"fs">]>;
                     jsonEntriesSha: z.ZodOptional<z.ZodString>;
+                    sourceMode: z.ZodOptional<z.ZodUnion<readonly [z.ZodLiteral<"managed">, z.ZodLiteral<"connected">]>>;
                     publishRefusal: z.ZodOptional<z.ZodObject<{
                         code: z.ZodLiteral<"no-base">;
                         message: z.ZodString;
@@ -466,6 +467,7 @@ export declare const Api: {
                     }, z.core.$strip>;
                     profileId: z.ZodNullable<z.ZodString>;
                     mode: z.ZodUnion<readonly [z.ZodLiteral<"http">, z.ZodLiteral<"fs">]>;
+                    sourceMode: z.ZodOptional<z.ZodUnion<readonly [z.ZodLiteral<"managed">, z.ZodLiteral<"connected">]>>;
                     publishRefusal: z.ZodOptional<z.ZodObject<{
                         code: z.ZodLiteral<"no-base">;
                         message: z.ZodString;

package/internal/dist/valbuild-shared-internal.cjs.dev.js

@@ -1864,6 +1864,27 @@ var Api = {
           profileId: zod.z.string().nullable(),
           mode: zod.z.union([zod.z.literal("http"), zod.z.literal("fs")]),
           jsonEntriesSha: zod.z.string().optional(),
+          /**
+           * How this project's SOURCE is kept, when the server knows.
+           *
+           * `"managed"` -- the content service is the store of record,
+           * there is no repository, and the Studio is the deployer: the
+           * build that makes a publish live happens in the tab that started
+           * it. `"connected"` -- commits are mirrored into a repository a
+           * host watches, so something outside the browser finishes the
+           * job.
+           *
+           * The Studio narrates a publish differently for each, because a
+           * `building` state in managed mode is a spinner with no event
+           * that can ever end it -- not on a reload, not on a retry, not
+           * tomorrow.
+           *
+           * Optional, and absent means "not reported", never "managed":
+           * `fs` mode has no project to have a mode, and so does an `http`
+           * server that predates the field. Both keep the connected story,
+           * which is the one the Studio has always told.
+           */
+          sourceMode: zod.z.union([zod.z.literal("managed"), zod.z.literal("connected")]).optional(),
           publishRefusal: PublishRefusal.optional()
         }), zod.z.object({
           type: zod.z.literal("use-websocket"),
@@ -1926,6 +1947,27 @@ var Api = {
           config: ValConfig,
           profileId: zod.z.string().nullable(),
           mode: zod.z.union([zod.z.literal("http"), zod.z.literal("fs")]),
+          /**
+           * How this project's SOURCE is kept, when the server knows.
+           *
+           * `"managed"` -- the content service is the store of record,
+           * there is no repository, and the Studio is the deployer: the
+           * build that makes a publish live happens in the tab that started
+           * it. `"connected"` -- commits are mirrored into a repository a
+           * host watches, so something outside the browser finishes the
+           * job.
+           *
+           * The Studio narrates a publish differently for each, because a
+           * `building` state in managed mode is a spinner with no event
+           * that can ever end it -- not on a reload, not on a retry, not
+           * tomorrow.
+           *
+           * Optional, and absent means "not reported", never "managed":
+           * `fs` mode has no project to have a mode, and so does an `http`
+           * server that predates the field. Both keep the connected story,
+           * which is the one the Studio has always told.
+           */
+          sourceMode: zod.z.union([zod.z.literal("managed"), zod.z.literal("connected")]).optional(),
           publishRefusal: PublishRefusal.optional()
         })])
       })])
@@ -3057,12 +3099,59 @@ var Api = {
 // `number` is allowed because the client stringifies every query value before it
 // goes on the URL (see createValClient), so a numeric param round-trips fine.
 
+/**
+ * How long an appended `details` may be before it is cut.
+ *
+ * A thrown DAL error in the content service quotes the whole offending ROW back
+ * — which for a patch is every op the editor just made — so an uncapped append
+ * puts kilobytes of JSON in a dialog. The head is where the cause is; the tail
+ * is the evidence, and it belongs in the service's own logs.
+ */
+var MAX_DETAILS_LENGTH = 500;
 function getErrorMessageFromUnknownJson(json, fallback) {
   if (getSitemapTree._typeof(json) === "object" && json !== null && "message" in json && typeof json.message === "string") {
-    return json.message;
+    var details = detailsOf(json);
+    if (details === null || details === json.message) {
+      return json.message;
+    }
+    return "".concat(json.message, ": ").concat(details);
   }
   return fallback;
 }
+
+/**
+ * The cause the content service put beside its message, when it wrote one a
+ * person can read.
+ *
+ * `HttpError` in `home` is `{ statusCode, message?, details? }`, and `details`
+ * is filled in two quite different ways. Where a handler REFUSED, it holds the
+ * structured zod error whose summary is already the `message` — repeating it
+ * adds nothing. Where a handler THREW, `sendResult` writes `message:
+ * "Internal Server Error"` and puts the exception's own message in `details` —
+ * so there the message says nothing and the details say everything.
+ *
+ * Which is why the test is the TYPE rather than the status code: a string
+ * `details` is prose meant to be read, an object is a payload meant to be
+ * parsed. This takes the first and leaves the second.
+ *
+ * It was written after an hour was lost to the second case. A patch save
+ * against a content service that threw showed the Studio exactly
+ * `"Internal Server Error"` and nothing else, in a dialog with no other clue,
+ * while the service's answer had been carrying the reason the whole time.
+ */
+function detailsOf(json) {
+  if (!("details" in json) || typeof json.details !== "string") {
+    return null;
+  }
+  var details = json.details.trim();
+  if (details === "") {
+    return null;
+  }
+  if (details.length <= MAX_DETAILS_LENGTH) {
+    return details;
+  }
+  return "".concat(details.slice(0, MAX_DETAILS_LENGTH), "\u2026");
+}
 var DEFAULT_ERROR_MESSAGE = "Unknown error with unknown message from server";
 
 var createValClient = function createValClient(host, config // We want to use this in the future

package/internal/dist/valbuild-shared-internal.cjs.prod.js

@@ -1864,6 +1864,27 @@ var Api = {
           profileId: zod.z.string().nullable(),
           mode: zod.z.union([zod.z.literal("http"), zod.z.literal("fs")]),
           jsonEntriesSha: zod.z.string().optional(),
+          /**
+           * How this project's SOURCE is kept, when the server knows.
+           *
+           * `"managed"` -- the content service is the store of record,
+           * there is no repository, and the Studio is the deployer: the
+           * build that makes a publish live happens in the tab that started
+           * it. `"connected"` -- commits are mirrored into a repository a
+           * host watches, so something outside the browser finishes the
+           * job.
+           *
+           * The Studio narrates a publish differently for each, because a
+           * `building` state in managed mode is a spinner with no event
+           * that can ever end it -- not on a reload, not on a retry, not
+           * tomorrow.
+           *
+           * Optional, and absent means "not reported", never "managed":
+           * `fs` mode has no project to have a mode, and so does an `http`
+           * server that predates the field. Both keep the connected story,
+           * which is the one the Studio has always told.
+           */
+          sourceMode: zod.z.union([zod.z.literal("managed"), zod.z.literal("connected")]).optional(),
           publishRefusal: PublishRefusal.optional()
         }), zod.z.object({
           type: zod.z.literal("use-websocket"),
@@ -1926,6 +1947,27 @@ var Api = {
           config: ValConfig,
           profileId: zod.z.string().nullable(),
           mode: zod.z.union([zod.z.literal("http"), zod.z.literal("fs")]),
+          /**
+           * How this project's SOURCE is kept, when the server knows.
+           *
+           * `"managed"` -- the content service is the store of record,
+           * there is no repository, and the Studio is the deployer: the
+           * build that makes a publish live happens in the tab that started
+           * it. `"connected"` -- commits are mirrored into a repository a
+           * host watches, so something outside the browser finishes the
+           * job.
+           *
+           * The Studio narrates a publish differently for each, because a
+           * `building` state in managed mode is a spinner with no event
+           * that can ever end it -- not on a reload, not on a retry, not
+           * tomorrow.
+           *
+           * Optional, and absent means "not reported", never "managed":
+           * `fs` mode has no project to have a mode, and so does an `http`
+           * server that predates the field. Both keep the connected story,
+           * which is the one the Studio has always told.
+           */
+          sourceMode: zod.z.union([zod.z.literal("managed"), zod.z.literal("connected")]).optional(),
           publishRefusal: PublishRefusal.optional()
         })])
       })])
@@ -3057,12 +3099,59 @@ var Api = {
 // `number` is allowed because the client stringifies every query value before it
 // goes on the URL (see createValClient), so a numeric param round-trips fine.
 
+/**
+ * How long an appended `details` may be before it is cut.
+ *
+ * A thrown DAL error in the content service quotes the whole offending ROW back
+ * — which for a patch is every op the editor just made — so an uncapped append
+ * puts kilobytes of JSON in a dialog. The head is where the cause is; the tail
+ * is the evidence, and it belongs in the service's own logs.
+ */
+var MAX_DETAILS_LENGTH = 500;
 function getErrorMessageFromUnknownJson(json, fallback) {
   if (getSitemapTree._typeof(json) === "object" && json !== null && "message" in json && typeof json.message === "string") {
-    return json.message;
+    var details = detailsOf(json);
+    if (details === null || details === json.message) {
+      return json.message;
+    }
+    return "".concat(json.message, ": ").concat(details);
   }
   return fallback;
 }
+
+/**
+ * The cause the content service put beside its message, when it wrote one a
+ * person can read.
+ *
+ * `HttpError` in `home` is `{ statusCode, message?, details? }`, and `details`
+ * is filled in two quite different ways. Where a handler REFUSED, it holds the
+ * structured zod error whose summary is already the `message` — repeating it
+ * adds nothing. Where a handler THREW, `sendResult` writes `message:
+ * "Internal Server Error"` and puts the exception's own message in `details` —
+ * so there the message says nothing and the details say everything.
+ *
+ * Which is why the test is the TYPE rather than the status code: a string
+ * `details` is prose meant to be read, an object is a payload meant to be
+ * parsed. This takes the first and leaves the second.
+ *
+ * It was written after an hour was lost to the second case. A patch save
+ * against a content service that threw showed the Studio exactly
+ * `"Internal Server Error"` and nothing else, in a dialog with no other clue,
+ * while the service's answer had been carrying the reason the whole time.
+ */
+function detailsOf(json) {
+  if (!("details" in json) || typeof json.details !== "string") {
+    return null;
+  }
+  var details = json.details.trim();
+  if (details === "") {
+    return null;
+  }
+  if (details.length <= MAX_DETAILS_LENGTH) {
+    return details;
+  }
+  return "".concat(details.slice(0, MAX_DETAILS_LENGTH), "\u2026");
+}
 var DEFAULT_ERROR_MESSAGE = "Unknown error with unknown message from server";
 
 var createValClient = function createValClient(host, config // We want to use this in the future

package/internal/dist/valbuild-shared-internal.esm.js

@@ -1857,6 +1857,27 @@ var Api = {
           profileId: z.string().nullable(),
           mode: z.union([z.literal("http"), z.literal("fs")]),
           jsonEntriesSha: z.string().optional(),
+          /**
+           * How this project's SOURCE is kept, when the server knows.
+           *
+           * `"managed"` -- the content service is the store of record,
+           * there is no repository, and the Studio is the deployer: the
+           * build that makes a publish live happens in the tab that started
+           * it. `"connected"` -- commits are mirrored into a repository a
+           * host watches, so something outside the browser finishes the
+           * job.
+           *
+           * The Studio narrates a publish differently for each, because a
+           * `building` state in managed mode is a spinner with no event
+           * that can ever end it -- not on a reload, not on a retry, not
+           * tomorrow.
+           *
+           * Optional, and absent means "not reported", never "managed":
+           * `fs` mode has no project to have a mode, and so does an `http`
+           * server that predates the field. Both keep the connected story,
+           * which is the one the Studio has always told.
+           */
+          sourceMode: z.union([z.literal("managed"), z.literal("connected")]).optional(),
           publishRefusal: PublishRefusal.optional()
         }), z.object({
           type: z.literal("use-websocket"),
@@ -1919,6 +1940,27 @@ var Api = {
           config: ValConfig,
           profileId: z.string().nullable(),
           mode: z.union([z.literal("http"), z.literal("fs")]),
+          /**
+           * How this project's SOURCE is kept, when the server knows.
+           *
+           * `"managed"` -- the content service is the store of record,
+           * there is no repository, and the Studio is the deployer: the
+           * build that makes a publish live happens in the tab that started
+           * it. `"connected"` -- commits are mirrored into a repository a
+           * host watches, so something outside the browser finishes the
+           * job.
+           *
+           * The Studio narrates a publish differently for each, because a
+           * `building` state in managed mode is a spinner with no event
+           * that can ever end it -- not on a reload, not on a retry, not
+           * tomorrow.
+           *
+           * Optional, and absent means "not reported", never "managed":
+           * `fs` mode has no project to have a mode, and so does an `http`
+           * server that predates the field. Both keep the connected story,
+           * which is the one the Studio has always told.
+           */
+          sourceMode: z.union([z.literal("managed"), z.literal("connected")]).optional(),
           publishRefusal: PublishRefusal.optional()
         })])
       })])
@@ -3050,12 +3092,59 @@ var Api = {
 // `number` is allowed because the client stringifies every query value before it
 // goes on the URL (see createValClient), so a numeric param round-trips fine.
 
+/**
+ * How long an appended `details` may be before it is cut.
+ *
+ * A thrown DAL error in the content service quotes the whole offending ROW back
+ * — which for a patch is every op the editor just made — so an uncapped append
+ * puts kilobytes of JSON in a dialog. The head is where the cause is; the tail
+ * is the evidence, and it belongs in the service's own logs.
+ */
+var MAX_DETAILS_LENGTH = 500;
 function getErrorMessageFromUnknownJson(json, fallback) {
   if (_typeof(json) === "object" && json !== null && "message" in json && typeof json.message === "string") {
-    return json.message;
+    var details = detailsOf(json);
+    if (details === null || details === json.message) {
+      return json.message;
+    }
+    return "".concat(json.message, ": ").concat(details);
   }
   return fallback;
 }
+
+/**
+ * The cause the content service put beside its message, when it wrote one a
+ * person can read.
+ *
+ * `HttpError` in `home` is `{ statusCode, message?, details? }`, and `details`
+ * is filled in two quite different ways. Where a handler REFUSED, it holds the
+ * structured zod error whose summary is already the `message` — repeating it
+ * adds nothing. Where a handler THREW, `sendResult` writes `message:
+ * "Internal Server Error"` and puts the exception's own message in `details` —
+ * so there the message says nothing and the details say everything.
+ *
+ * Which is why the test is the TYPE rather than the status code: a string
+ * `details` is prose meant to be read, an object is a payload meant to be
+ * parsed. This takes the first and leaves the second.
+ *
+ * It was written after an hour was lost to the second case. A patch save
+ * against a content service that threw showed the Studio exactly
+ * `"Internal Server Error"` and nothing else, in a dialog with no other clue,
+ * while the service's answer had been carrying the reason the whole time.
+ */
+function detailsOf(json) {
+  if (!("details" in json) || typeof json.details !== "string") {
+    return null;
+  }
+  var details = json.details.trim();
+  if (details === "") {
+    return null;
+  }
+  if (details.length <= MAX_DETAILS_LENGTH) {
+    return details;
+  }
+  return "".concat(details.slice(0, MAX_DETAILS_LENGTH), "\u2026");
+}
 var DEFAULT_ERROR_MESSAGE = "Unknown error with unknown message from server";
 
 var createValClient = function createValClient(host, config // We want to use this in the future

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@valbuild/shared",
-  "version": "0.134.0",
+  "version": "0.136.0",
   "private": false,
   "description": "Val shared types and utilities",
   "repository": {
@@ -37,7 +37,7 @@
     "flexsearch": "^0.8.212",
     "zod": "^4.4.3",
     "zod-validation-error": "^5.0.0",
-    "@valbuild/core": "0.134.0"
+    "@valbuild/core": "0.136.0"
   },
   "files": [
     "CHANGELOG.md",