@valbuild/server 0.135.0 → 0.136.0

package/CHANGELOG.md

@@ -1,5 +1,91 @@
 # @valbuild/server
 
+## 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
+
+- [#699](https://github.com/valbuild/val/pull/699) [`1d72d00`](https://github.com/valbuild/val/commit/1d72d00a1b036959ae0f1540121701cbb2694dcb) Thanks [@freekh](https://github.com/freekh)! - A `*.val.ts` with no default export is no longer reported as a missing module
+
+  `*.val.ts` is a naming convention, not a promise: plenty of files under it hold
+  only the schemas and helpers the modules beside them import. Every one of those
+  was getting two errors in the editor — `Module '…' was not found in
+val.modules` and `… is not registered in val.modules, so Val will not serve it`
+  — both on line 1, telling their author to register a file that has nothing to
+  register. `val validate` has never reported them; only the editor did.
+
+  The default export is what makes a `*.val.ts` a module, so that is what the
+  diagnostic now asks about:
+
+  - **No default export → nothing is reported.** The file is not a module, so it
+    is not a module Val is failing to serve.
+  - **A default export → one diagnostic, on the `export default` itself** rather
+    than on line 1, so it is next to the thing that has to change, and the
+    duplicate fatal beside it is gone. The message now gives both remedies: add
+    the file to `val.modules`, or export what it holds by name instead. The "Val:
+    register … in val.modules" quick fix is offered there.
+
+  The rule is `findDefaultExport` in `@valbuild/server`, which `val validate`
+  already used to decide the same question — so the editor and the CLI now agree
+  about which files are modules, including the cases that are easy to get wrong
+  (`export * from …` carries no default; `export type { T as default }` and
+  `export default interface T {}` are both gone after transpilation).
+
+  Because the diagnostic now replaces a module's own findings rather than adding
+  to them, the editor also stops guessing about registration it cannot read: a
+  `val.modules` that registers modules through a tsconfig path alias
+  (`import("_/content/page.val")`), or that builds its list in another file, is no
+  longer taken to register nothing.
+
+- Updated dependencies [[`f3a4bb7`](https://github.com/valbuild/val/commit/f3a4bb7aea604943b92545c122243798c759715c)]:
+  - @valbuild/ui@0.136.0
+  - @valbuild/core@0.136.0
+  - @valbuild/shared@0.136.0
+
 ## 0.135.0
 
 ### Patch Changes

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

@@ -417,6 +417,22 @@ export declare abstract class ValOps {
      * project requires.
      */
     publishRefusal(): PublishRefusal | null;
+    /**
+     * How this project's SOURCE is kept, or `null` when it is nobody's question.
+     *
+     * `"managed"` -- the content service is the store of record, there is no
+     * repository, and nothing outside the browser will ever pick a commit up.
+     * `"connected"` -- commits are mirrored into a repository a host watches.
+     *
+     * `null` is the honest answer for `fs` and memory mode, where publishing is
+     * writing to disk and there is no project to have a mode, and for an `http`
+     * project whose content service predates the field. The Studio treats it as
+     * "the story I have always told", which is the connected one -- the feed, and
+     * a `building` state that something outside resolves. Guessing `managed`
+     * instead would take the deploy feed away from every project running against
+     * an older service.
+     */
+    sourceMode(): "managed" | "connected" | null;
     /**
      * Whether a commit here produces `.val.ts` TEXT as well as data.
      *

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

@@ -126,6 +126,21 @@ export declare class ValOpsHttp extends ValOps {
      * checking.
      */
     publishRefusal(): PublishRefusal | null;
+    /**
+     * What the content service last said this project's source mode is.
+     *
+     * Read off the same remembered expectation {@link publishRefusal} uses. It is
+     * CURRENT wherever it matters rather than a poll behind, and by construction
+     * rather than by luck: the only caller is `/stat`, which awaits `getStat`
+     * first, and that fetches the patches -- which is the response the expectation
+     * is recorded from.
+     *
+     * `null` before anything has fetched patches, which is the same "not
+     * reported" the wire field means, and reads as connected. The alternative
+     * would be to ask for it separately, which is a round trip for a field that
+     * has just arrived.
+     */
+    sourceMode(): "managed" | "connected" | null;
     onInit(): Promise<void>;
     getPresignedAuthNonce(profileId: string, corsOrigin: string): Promise<{
         status: "success";

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

@@ -44,7 +44,7 @@ export type { ModulePathMap } from "./modulePathMap.js";
 export { ValOpsFS } from "./ValOpsFS.js";
 export { ValOpsHttp } from "./ValOpsHttp.js";
 export { ValOpsMemory, InMemoryPatchStore, type ValPatchStore, type StoredPatch, type ValOpsMemoryOptions, } from "./ValOpsMemory.js";
-export { loadValModules, createValModuleFileInspector } from "./loadValModules.js";
+export { loadValModules, createValModuleFileInspector, findDefaultExport, } from "./loadValModules.js";
 export type { ValModuleFileInspection } from "./loadValModules.js";
 export { formatPatchSourceError } from "./ValOps.js";
 export { compareWithCapturedReport, readCapturedReport, replaySnapshot, } from "./debug/replaySnapshot.js";

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

@@ -71,3 +71,26 @@ export type ValModuleFileInspection =
  * project's own first-party files.
  */
 export declare function createValModuleFileInspector(projectRoot: string, host?: ValModulesHost): (absPath: string) => ValModuleFileInspection;
+/**
+ * The statement that exports a RUNTIME value as `default`, without evaluating
+ * it — or `undefined` when the file has no such export.
+ *
+ * This is the one rule that separates a Val module from a `*.val.ts` that
+ * merely wears the naming convention: a shared schema or helper is exported by
+ * name, a module is exported by default. Every caller that needs to tell those
+ * apart goes through this — `val validate` to decide whether an unregistered
+ * file is worth reporting, and the language server to decide the same thing and
+ * to put its diagnostic on the export rather than on line 1.
+ *
+ * Two things deliberately do not count, because neither exists once the file is
+ * transpiled — and treating either as a default export would send a pure helper
+ * off to be evaluated and reported:
+ *
+ *  - `export * from "./x"`, since a star re-export never carries the default;
+ *  - a type-only export, in any of its three spellings
+ *    (`export type { T as default }`, `export { type T as default }` and
+ *    `export default interface T {}` — the last one parses as a declaration
+ *    carrying a `default` modifier, exactly like `export default class`, and is
+ *    the one that looks like a runtime export and is not).
+ */
+export declare function findDefaultExport(sourceFile: ts.SourceFile): ts.Statement | undefined;

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

@@ -1007,18 +1007,29 @@ function createValModuleFileInspector(projectRoot, host = ts__default["default"]
 }
 
 /**
- * Whether the file exports a RUNTIME value as `default`, without evaluating it.
+ * The statement that exports a RUNTIME value as `default`, without evaluating
+ * it — or `undefined` when the file has no such export.
+ *
+ * This is the one rule that separates a Val module from a `*.val.ts` that
+ * merely wears the naming convention: a shared schema or helper is exported by
+ * name, a module is exported by default. Every caller that needs to tell those
+ * apart goes through this — `val validate` to decide whether an unregistered
+ * file is worth reporting, and the language server to decide the same thing and
+ * to put its diagnostic on the export rather than on line 1.
  *
  * Two things deliberately do not count, because neither exists once the file is
  * transpiled — and treating either as a default export would send a pure helper
  * off to be evaluated and reported:
  *
  *  - `export * from "./x"`, since a star re-export never carries the default;
- *  - a type-only export, in either of its spellings
- *    (`export type { T as default }` and `export { type T as default }`).
+ *  - a type-only export, in any of its three spellings
+ *    (`export type { T as default }`, `export { type T as default }` and
+ *    `export default interface T {}` — the last one parses as a declaration
+ *    carrying a `default` modifier, exactly like `export default class`, and is
+ *    the one that looks like a runtime export and is not).
  */
-function hasDefaultExport(sourceFile) {
-  return sourceFile.statements.some(statement => {
+function findDefaultExport(sourceFile) {
+  return sourceFile.statements.find(statement => {
     // `export default <expr>` — but not `export = x`, which shares this node.
     if (ts__default["default"].isExportAssignment(statement)) {
       return !statement.isExportEquals;
@@ -1029,10 +1040,17 @@ function hasDefaultExport(sourceFile) {
     }
     // `export default function f() {}` / `export default class C {}`, which are
     // declarations carrying a `default` modifier rather than export assignments.
-    return ts__default["default"].canHaveModifiers(statement) && (ts__default["default"].getModifiers(statement) ?? []).some(modifier => modifier.kind === ts__default["default"].SyntaxKind.DefaultKeyword);
+    // `export default interface T {}` is spelled the same way and is a type, so
+    // it is excluded here rather than by the `isTypeOnly` checks above.
+    return !ts__default["default"].isInterfaceDeclaration(statement) && ts__default["default"].canHaveModifiers(statement) && (ts__default["default"].getModifiers(statement) ?? []).some(modifier => modifier.kind === ts__default["default"].SyntaxKind.DefaultKeyword);
   });
 }
 
+/** Whether the file exports a runtime value as `default`. */
+function hasDefaultExport(sourceFile) {
+  return findDefaultExport(sourceFile) !== undefined;
+}
+
 /** A short, human-readable "what you exported instead" for the error message. */
 function describeDefaultExport(value) {
   if (value === null) {
@@ -4558,6 +4576,25 @@ class ValOps {
     return null;
   }
 
+  /**
+   * How this project's SOURCE is kept, or `null` when it is nobody's question.
+   *
+   * `"managed"` -- the content service is the store of record, there is no
+   * repository, and nothing outside the browser will ever pick a commit up.
+   * `"connected"` -- commits are mirrored into a repository a host watches.
+   *
+   * `null` is the honest answer for `fs` and memory mode, where publishing is
+   * writing to disk and there is no project to have a mode, and for an `http`
+   * project whose content service predates the field. The Studio treats it as
+   * "the story I have always told", which is the connected one -- the feed, and
+   * a `building` state that something outside resolves. Guessing `managed`
+   * instead would take the deploy feed away from every project running against
+   * an older service.
+   */
+  sourceMode() {
+    return null;
+  }
+
   /**
    * Whether a commit here produces `.val.ts` TEXT as well as data.
    *
@@ -7917,6 +7954,25 @@ class ValOpsHttp extends ValOps {
       message: `This project mirrors its content into a git repository (branch ` + `'${this.projectExpectation.branch}'), but this deployment was not ` + "built from one, so it does not know which commit to write that " + "mirror against. Publishing would save the content and silently " + "leave the repository behind. Deploy this project again from its " + "repository, and publishing will work from that build on."
     };
   }
+
+  /**
+   * What the content service last said this project's source mode is.
+   *
+   * Read off the same remembered expectation {@link publishRefusal} uses. It is
+   * CURRENT wherever it matters rather than a poll behind, and by construction
+   * rather than by luck: the only caller is `/stat`, which awaits `getStat`
+   * first, and that fetches the patches -- which is the response the expectation
+   * is recorded from.
+   *
+   * `null` before anything has fetched patches, which is the same "not
+   * reported" the wire field means, and reads as connected. The alternative
+   * would be to ask for it separately, which is a round trip for a field that
+   * has just arrived.
+   */
+  sourceMode() {
+    var _this$projectExpectat2;
+    return ((_this$projectExpectat2 = this.projectExpectation) === null || _this$projectExpectat2 === void 0 ? void 0 : _this$projectExpectat2.sourceMode) ?? null;
+  }
   async onInit() {
     // TODO: unused for now. Implement or remove
   }
@@ -11898,6 +11954,16 @@ const ValServer = (valModules, options, callbacks) => {
          * it failed to compute.
          */
         const publishRefusal = serverOps.publishRefusal();
+        /*
+         * How this project's source is kept, when the store knows.
+         *
+         * Spread for the same reason `publishRefusal` is: absent has to keep
+         * meaning "not reported" rather than becoming a mode. The Studio
+         * narrates a publish differently for a managed project -- there is
+         * nothing outside the browser to finish it -- so a wrong default here
+         * shows one story to a project that lives by the other.
+         */
+        const sourceMode = serverOps.sourceMode();
         return {
           status: 200,
           json: {
@@ -11907,6 +11973,9 @@ const ValServer = (valModules, options, callbacks) => {
             ...(publishRefusal ? {
               publishRefusal
             } : {}),
+            ...(sourceMode ? {
+              sourceMode
+            } : {}),
             config: options.config
           }
         };
@@ -18039,6 +18108,7 @@ exports.extractFileMetadata = extractFileMetadata;
 exports.extractImageMetadata = extractImageMetadata;
 exports.extractJsonValuesEntry = extractJsonValuesEntry;
 exports.findAndEvalValConfigFile = findAndEvalValConfigFile;
+exports.findDefaultExport = findDefaultExport;
 exports.findJsonEntryFilePath = findJsonEntryFilePath;
 exports.fixHandlers = fixHandlers;
 exports.formatPatchSourceError = formatPatchSourceError;

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

@@ -1007,18 +1007,29 @@ function createValModuleFileInspector(projectRoot, host = ts__default["default"]
 }
 
 /**
- * Whether the file exports a RUNTIME value as `default`, without evaluating it.
+ * The statement that exports a RUNTIME value as `default`, without evaluating
+ * it — or `undefined` when the file has no such export.
+ *
+ * This is the one rule that separates a Val module from a `*.val.ts` that
+ * merely wears the naming convention: a shared schema or helper is exported by
+ * name, a module is exported by default. Every caller that needs to tell those
+ * apart goes through this — `val validate` to decide whether an unregistered
+ * file is worth reporting, and the language server to decide the same thing and
+ * to put its diagnostic on the export rather than on line 1.
  *
  * Two things deliberately do not count, because neither exists once the file is
  * transpiled — and treating either as a default export would send a pure helper
  * off to be evaluated and reported:
  *
  *  - `export * from "./x"`, since a star re-export never carries the default;
- *  - a type-only export, in either of its spellings
- *    (`export type { T as default }` and `export { type T as default }`).
+ *  - a type-only export, in any of its three spellings
+ *    (`export type { T as default }`, `export { type T as default }` and
+ *    `export default interface T {}` — the last one parses as a declaration
+ *    carrying a `default` modifier, exactly like `export default class`, and is
+ *    the one that looks like a runtime export and is not).
  */
-function hasDefaultExport(sourceFile) {
-  return sourceFile.statements.some(statement => {
+function findDefaultExport(sourceFile) {
+  return sourceFile.statements.find(statement => {
     // `export default <expr>` — but not `export = x`, which shares this node.
     if (ts__default["default"].isExportAssignment(statement)) {
       return !statement.isExportEquals;
@@ -1029,10 +1040,17 @@ function hasDefaultExport(sourceFile) {
     }
     // `export default function f() {}` / `export default class C {}`, which are
     // declarations carrying a `default` modifier rather than export assignments.
-    return ts__default["default"].canHaveModifiers(statement) && (ts__default["default"].getModifiers(statement) ?? []).some(modifier => modifier.kind === ts__default["default"].SyntaxKind.DefaultKeyword);
+    // `export default interface T {}` is spelled the same way and is a type, so
+    // it is excluded here rather than by the `isTypeOnly` checks above.
+    return !ts__default["default"].isInterfaceDeclaration(statement) && ts__default["default"].canHaveModifiers(statement) && (ts__default["default"].getModifiers(statement) ?? []).some(modifier => modifier.kind === ts__default["default"].SyntaxKind.DefaultKeyword);
   });
 }
 
+/** Whether the file exports a runtime value as `default`. */
+function hasDefaultExport(sourceFile) {
+  return findDefaultExport(sourceFile) !== undefined;
+}
+
 /** A short, human-readable "what you exported instead" for the error message. */
 function describeDefaultExport(value) {
   if (value === null) {
@@ -4558,6 +4576,25 @@ class ValOps {
     return null;
   }
 
+  /**
+   * How this project's SOURCE is kept, or `null` when it is nobody's question.
+   *
+   * `"managed"` -- the content service is the store of record, there is no
+   * repository, and nothing outside the browser will ever pick a commit up.
+   * `"connected"` -- commits are mirrored into a repository a host watches.
+   *
+   * `null` is the honest answer for `fs` and memory mode, where publishing is
+   * writing to disk and there is no project to have a mode, and for an `http`
+   * project whose content service predates the field. The Studio treats it as
+   * "the story I have always told", which is the connected one -- the feed, and
+   * a `building` state that something outside resolves. Guessing `managed`
+   * instead would take the deploy feed away from every project running against
+   * an older service.
+   */
+  sourceMode() {
+    return null;
+  }
+
   /**
    * Whether a commit here produces `.val.ts` TEXT as well as data.
    *
@@ -7917,6 +7954,25 @@ class ValOpsHttp extends ValOps {
       message: `This project mirrors its content into a git repository (branch ` + `'${this.projectExpectation.branch}'), but this deployment was not ` + "built from one, so it does not know which commit to write that " + "mirror against. Publishing would save the content and silently " + "leave the repository behind. Deploy this project again from its " + "repository, and publishing will work from that build on."
     };
   }
+
+  /**
+   * What the content service last said this project's source mode is.
+   *
+   * Read off the same remembered expectation {@link publishRefusal} uses. It is
+   * CURRENT wherever it matters rather than a poll behind, and by construction
+   * rather than by luck: the only caller is `/stat`, which awaits `getStat`
+   * first, and that fetches the patches -- which is the response the expectation
+   * is recorded from.
+   *
+   * `null` before anything has fetched patches, which is the same "not
+   * reported" the wire field means, and reads as connected. The alternative
+   * would be to ask for it separately, which is a round trip for a field that
+   * has just arrived.
+   */
+  sourceMode() {
+    var _this$projectExpectat2;
+    return ((_this$projectExpectat2 = this.projectExpectation) === null || _this$projectExpectat2 === void 0 ? void 0 : _this$projectExpectat2.sourceMode) ?? null;
+  }
   async onInit() {
     // TODO: unused for now. Implement or remove
   }
@@ -11898,6 +11954,16 @@ const ValServer = (valModules, options, callbacks) => {
          * it failed to compute.
          */
         const publishRefusal = serverOps.publishRefusal();
+        /*
+         * How this project's source is kept, when the store knows.
+         *
+         * Spread for the same reason `publishRefusal` is: absent has to keep
+         * meaning "not reported" rather than becoming a mode. The Studio
+         * narrates a publish differently for a managed project -- there is
+         * nothing outside the browser to finish it -- so a wrong default here
+         * shows one story to a project that lives by the other.
+         */
+        const sourceMode = serverOps.sourceMode();
         return {
           status: 200,
           json: {
@@ -11907,6 +11973,9 @@ const ValServer = (valModules, options, callbacks) => {
             ...(publishRefusal ? {
               publishRefusal
             } : {}),
+            ...(sourceMode ? {
+              sourceMode
+            } : {}),
             config: options.config
           }
         };
@@ -18039,6 +18108,7 @@ exports.extractFileMetadata = extractFileMetadata;
 exports.extractImageMetadata = extractImageMetadata;
 exports.extractJsonValuesEntry = extractJsonValuesEntry;
 exports.findAndEvalValConfigFile = findAndEvalValConfigFile;
+exports.findDefaultExport = findDefaultExport;
 exports.findJsonEntryFilePath = findJsonEntryFilePath;
 exports.fixHandlers = fixHandlers;
 exports.formatPatchSourceError = formatPatchSourceError;

package/dist/valbuild-server.esm.js

@@ -973,18 +973,29 @@ function createValModuleFileInspector(projectRoot, host = ts.sys) {
 }
 
 /**
- * Whether the file exports a RUNTIME value as `default`, without evaluating it.
+ * The statement that exports a RUNTIME value as `default`, without evaluating
+ * it — or `undefined` when the file has no such export.
+ *
+ * This is the one rule that separates a Val module from a `*.val.ts` that
+ * merely wears the naming convention: a shared schema or helper is exported by
+ * name, a module is exported by default. Every caller that needs to tell those
+ * apart goes through this — `val validate` to decide whether an unregistered
+ * file is worth reporting, and the language server to decide the same thing and
+ * to put its diagnostic on the export rather than on line 1.
  *
  * Two things deliberately do not count, because neither exists once the file is
  * transpiled — and treating either as a default export would send a pure helper
  * off to be evaluated and reported:
  *
  *  - `export * from "./x"`, since a star re-export never carries the default;
- *  - a type-only export, in either of its spellings
- *    (`export type { T as default }` and `export { type T as default }`).
+ *  - a type-only export, in any of its three spellings
+ *    (`export type { T as default }`, `export { type T as default }` and
+ *    `export default interface T {}` — the last one parses as a declaration
+ *    carrying a `default` modifier, exactly like `export default class`, and is
+ *    the one that looks like a runtime export and is not).
  */
-function hasDefaultExport(sourceFile) {
-  return sourceFile.statements.some(statement => {
+function findDefaultExport(sourceFile) {
+  return sourceFile.statements.find(statement => {
     // `export default <expr>` — but not `export = x`, which shares this node.
     if (ts.isExportAssignment(statement)) {
       return !statement.isExportEquals;
@@ -995,10 +1006,17 @@ function hasDefaultExport(sourceFile) {
     }
     // `export default function f() {}` / `export default class C {}`, which are
     // declarations carrying a `default` modifier rather than export assignments.
-    return ts.canHaveModifiers(statement) && (ts.getModifiers(statement) ?? []).some(modifier => modifier.kind === ts.SyntaxKind.DefaultKeyword);
+    // `export default interface T {}` is spelled the same way and is a type, so
+    // it is excluded here rather than by the `isTypeOnly` checks above.
+    return !ts.isInterfaceDeclaration(statement) && ts.canHaveModifiers(statement) && (ts.getModifiers(statement) ?? []).some(modifier => modifier.kind === ts.SyntaxKind.DefaultKeyword);
   });
 }
 
+/** Whether the file exports a runtime value as `default`. */
+function hasDefaultExport(sourceFile) {
+  return findDefaultExport(sourceFile) !== undefined;
+}
+
 /** A short, human-readable "what you exported instead" for the error message. */
 function describeDefaultExport(value) {
   if (value === null) {
@@ -4524,6 +4542,25 @@ class ValOps {
     return null;
   }
 
+  /**
+   * How this project's SOURCE is kept, or `null` when it is nobody's question.
+   *
+   * `"managed"` -- the content service is the store of record, there is no
+   * repository, and nothing outside the browser will ever pick a commit up.
+   * `"connected"` -- commits are mirrored into a repository a host watches.
+   *
+   * `null` is the honest answer for `fs` and memory mode, where publishing is
+   * writing to disk and there is no project to have a mode, and for an `http`
+   * project whose content service predates the field. The Studio treats it as
+   * "the story I have always told", which is the connected one -- the feed, and
+   * a `building` state that something outside resolves. Guessing `managed`
+   * instead would take the deploy feed away from every project running against
+   * an older service.
+   */
+  sourceMode() {
+    return null;
+  }
+
   /**
    * Whether a commit here produces `.val.ts` TEXT as well as data.
    *
@@ -7883,6 +7920,25 @@ class ValOpsHttp extends ValOps {
       message: `This project mirrors its content into a git repository (branch ` + `'${this.projectExpectation.branch}'), but this deployment was not ` + "built from one, so it does not know which commit to write that " + "mirror against. Publishing would save the content and silently " + "leave the repository behind. Deploy this project again from its " + "repository, and publishing will work from that build on."
     };
   }
+
+  /**
+   * What the content service last said this project's source mode is.
+   *
+   * Read off the same remembered expectation {@link publishRefusal} uses. It is
+   * CURRENT wherever it matters rather than a poll behind, and by construction
+   * rather than by luck: the only caller is `/stat`, which awaits `getStat`
+   * first, and that fetches the patches -- which is the response the expectation
+   * is recorded from.
+   *
+   * `null` before anything has fetched patches, which is the same "not
+   * reported" the wire field means, and reads as connected. The alternative
+   * would be to ask for it separately, which is a round trip for a field that
+   * has just arrived.
+   */
+  sourceMode() {
+    var _this$projectExpectat2;
+    return ((_this$projectExpectat2 = this.projectExpectation) === null || _this$projectExpectat2 === void 0 ? void 0 : _this$projectExpectat2.sourceMode) ?? null;
+  }
   async onInit() {
     // TODO: unused for now. Implement or remove
   }
@@ -11864,6 +11920,16 @@ const ValServer = (valModules, options, callbacks) => {
          * it failed to compute.
          */
         const publishRefusal = serverOps.publishRefusal();
+        /*
+         * How this project's source is kept, when the store knows.
+         *
+         * Spread for the same reason `publishRefusal` is: absent has to keep
+         * meaning "not reported" rather than becoming a mode. The Studio
+         * narrates a publish differently for a managed project -- there is
+         * nothing outside the browser to finish it -- so a wrong default here
+         * shows one story to a project that lives by the other.
+         */
+        const sourceMode = serverOps.sourceMode();
         return {
           status: 200,
           json: {
@@ -11873,6 +11939,9 @@ const ValServer = (valModules, options, callbacks) => {
             ...(publishRefusal ? {
               publishRefusal
             } : {}),
+            ...(sourceMode ? {
+              sourceMode
+            } : {}),
             config: options.config
           }
         };
@@ -17961,4 +18030,4 @@ function readCapturedReport(snapshotDir) {
   return JSON.parse(fs.readFileSync(reportPath, "utf-8"));
 }
 
-export { DEFAULT_LOGIN_EXPIRES_IN_SECONDS, DEFAULT_LOGIN_HOST, DEFAULT_LOGIN_POLL_INTERVAL_SECONDS, EXTERNAL_RESULT, InMemoryPatchStore, Service, ValFSHost, ValLoginError, ValModuleLoader, ValOpsFS, ValOpsHttp, ValOpsMemory, ValSourceFileHandler, analyzeValModule, awaitValLoginConfirmation, checkRemoteRef, classifyJsonValuesOp, compareWithCapturedReport, createDefaultValFSHost, createFixPatch, createJsonEntryPathMap, createModulePathMap, createPrettierFormatter, createService, createValApiRouter, createValModuleFileInspector, createValOps, createValServer, currentFixHandlers, decodeJwtWithoutVerifying, defineExternal, describePatchStoreProblems, downloadFileFromRemote, encodeJwt, err, evalValConfigFile, extractFileMetadata, extractImageMetadata, extractJsonValuesEntry, findAndEvalValConfigFile, findJsonEntryFilePath, fixHandlers, formatPatchSourceError, formatSyntaxErrorTree, getCachedRemoteFileDir, getCachedRemoteFilePath, getCompilerOptions, getExpire, getFileExt, getModulePathRange, getPersonalAccessTokenPath, getSettings, getValidationErrorFileRef, handleCheckAllFiles, handleExternalUpload, handleFileMetadata, handleJsonValuesExtractEntry, handleRemoteFileCheck, handleRemoteFileDownload, handleRemoteFileUpload, handleRemoteGalleryFileUpload, handleUniqueFolderCheck, initHandlerOptions, isExternalResult, loadValModules, ok, parsePersonalAccessTokenFile, patchSourceFile, persistPersonalAccessToken, planJsonValuesEntryExtraction, readCapturedReport, readPatchStore, rebaseContentOp, replaySnapshot, resolveRemoteFileAuth, safeReadGit, startValLogin, uploadRemoteFile, validateMetadata, verifyJwt };
+export { DEFAULT_LOGIN_EXPIRES_IN_SECONDS, DEFAULT_LOGIN_HOST, DEFAULT_LOGIN_POLL_INTERVAL_SECONDS, EXTERNAL_RESULT, InMemoryPatchStore, Service, ValFSHost, ValLoginError, ValModuleLoader, ValOpsFS, ValOpsHttp, ValOpsMemory, ValSourceFileHandler, analyzeValModule, awaitValLoginConfirmation, checkRemoteRef, classifyJsonValuesOp, compareWithCapturedReport, createDefaultValFSHost, createFixPatch, createJsonEntryPathMap, createModulePathMap, createPrettierFormatter, createService, createValApiRouter, createValModuleFileInspector, createValOps, createValServer, currentFixHandlers, decodeJwtWithoutVerifying, defineExternal, describePatchStoreProblems, downloadFileFromRemote, encodeJwt, err, evalValConfigFile, extractFileMetadata, extractImageMetadata, extractJsonValuesEntry, findAndEvalValConfigFile, findDefaultExport, findJsonEntryFilePath, fixHandlers, formatPatchSourceError, formatSyntaxErrorTree, getCachedRemoteFileDir, getCachedRemoteFilePath, getCompilerOptions, getExpire, getFileExt, getModulePathRange, getPersonalAccessTokenPath, getSettings, getValidationErrorFileRef, handleCheckAllFiles, handleExternalUpload, handleFileMetadata, handleJsonValuesExtractEntry, handleRemoteFileCheck, handleRemoteFileDownload, handleRemoteFileUpload, handleRemoteGalleryFileUpload, handleUniqueFolderCheck, initHandlerOptions, isExternalResult, loadValModules, ok, parsePersonalAccessTokenFile, patchSourceFile, persistPersonalAccessToken, planJsonValuesEntryExtraction, readCapturedReport, readPatchStore, rebaseContentOp, replaySnapshot, resolveRemoteFileAuth, safeReadGit, startValLogin, uploadRemoteFile, validateMetadata, verifyJwt };

package/package.json

@@ -16,7 +16,7 @@
     "./package.json": "./package.json"
   },
   "types": "dist/valbuild-server.cjs.d.ts",
-  "version": "0.135.0",
+  "version": "0.136.0",
   "devDependencies": {
     "@prettier/sync": "^0.6.1",
     "@types/jest": "^30.0.0",
@@ -30,9 +30,9 @@
     "typescript": "^6.0.3",
     "zod": "^4.4.3",
     "zod-validation-error": "^5.0.0",
-    "@valbuild/core": "0.134.0",
-    "@valbuild/shared": "0.134.1",
-    "@valbuild/ui": "0.134.0"
+    "@valbuild/core": "0.136.0",
+    "@valbuild/shared": "0.136.0",
+    "@valbuild/ui": "0.136.0"
   },
   "engines": {
     "node": "^20.19.0 || >=22"