@valbuild/server 0.134.1 → 0.136.0

package/CHANGELOG.md

@@ -1,5 +1,151 @@
 # @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
+
+- [#707](https://github.com/valbuild/val/pull/707) [`c9affec`](https://github.com/valbuild/val/commit/c9affece6ae6ba62bd6c1113ed1fdab6317fa112) Thanks [@freekh](https://github.com/freekh)! - `val validate --fix` now formats with your prettier config instead of prettier's defaults
+
+  `--fix` formatted the files it repaired by calling `prettier.format(code, { filepath })`, which never reads `.prettierrc`: `filepath` picks the parser and nothing else — only `resolveConfig`, `getFileInfo` and prettier's own CLI consult the config. On a project whose style is not prettier's default, a two-line content fix therefore arrived as a whole-file rewrite, and in a repo with a format check in CI it turned a content fix into a red build.
+
+  There is now one implementation of "format a written file the way this project does", `createPrettierFormatter`, exported from `@valbuild/server` and re-exported by `@valbuild/next/server` and `@valbuild/tanstack/server`. It resolves `.prettierrc` for each file (including any `overrides` that match it), leaves anything in `.prettierignore` untouched, and falls back to prettier's defaults when the project has no config. `val validate --fix` uses it, so the CLI and the Studio can no longer disagree about formatting.
+
+  Use it for your app's `formatter` too — this is the recommended setup, and it replaces reading `.prettierrc.json` by hand:
+
+  ```ts
+  import prettier from "prettier";
+  import {
+    initValServer,
+    createPrettierFormatter,
+  } from "@valbuild/next/server";
+
+  const { valNextAppRouter } = initValServer(
+    valModules,
+    { ...config },
+    {
+      draftMode,
+      formatter: createPrettierFormatter(prettier, {
+        projectRoot: process.cwd(),
+      }),
+    },
+  );
+  ```
+
+  Existing `formatter` callbacks keep working unchanged.
+
+- [#706](https://github.com/valbuild/val/pull/706) [`72a7ca7`](https://github.com/valbuild/val/commit/72a7ca78354fff00e37a51359b17fba9334dc5e6) Thanks [@freekh](https://github.com/freekh)! - An endpoint that throws now answers Val's own 500 instead of the framework's.
+
+  Nothing caught a throw from an endpoint implementation, so it left the Val
+  router entirely and became whatever the host does with an unhandled error. On
+  TanStack Start that is h3, which replaces the message with the literal string
+  `"HTTPError"` and drops the stack — the same five words for a missing project,
+  a bad cookie and a module that failed to link — and keeps the real cause on the
+  server console. Where that console cannot be read (a Cloudflare Worker, for
+  one), a Val server had no way to say what broke inside it.
+
+  Such a request now answers Val's usual error envelope, naming the route, the
+  method and the cause:
+
+  ```json
+  {
+    "message": "Val: GET /authorize failed: Project is not set",
+    "details": {
+      "route": "/authorize",
+      "method": "GET",
+      "error": "Project is not set"
+    }
+  }
+  ```
+
+  The stack is logged rather than returned: `/authorize` and `/enable` are
+  reachable without a session, and the message is the part a caller can act on.
+
 ## 0.134.1
 
 ### 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/createPrettierFormatter.d.ts

@@ -0,0 +1,87 @@
+/**
+ * What Val calls to format a file it has just written.
+ *
+ * The same shape `initValServer`, `initValMcp` and `ValOps` take as their
+ * `formatter` option. The path is the file's path INSIDE the project — a
+ * `ModuleFilePath` such as `/content/page.val.ts`, or a `*.val.json` entry
+ * beside it — never an absolute path on disk, because the writers that call it
+ * (`ValOps.prepare`, the CLI's `--fix`) only ever know a module by that path.
+ */
+export type ValFormatter = (code: string, filePath: string) => Promise<string> | string;
+/**
+ * Prettier's options, as far as this file is concerned.
+ *
+ * Deliberately opaque: this file never reads an option, it only carries the
+ * bag from `resolveConfig` to `format`. Naming the real `Options` here would
+ * make it a compile error to build `@valbuild/server` in a project that has no
+ * prettier installed, which is most of them — prettier is a dependency the app
+ * opts into, so it is passed IN rather than imported.
+ */
+export type PrettierLikeConfig = object;
+/**
+ * `prettier`, as this file wants it.
+ *
+ * Structural for the same reason `SharpLike` in `@valbuild/mcp` is: a type-only
+ * import of a package that is not installed is still a compile error, and this
+ * package has to typecheck without prettier. `createPrettierFormatter.test.ts`
+ * asserts the real library against this type so the structural description
+ * cannot drift away from it unnoticed.
+ *
+ * Every result is `T | Promise<T>` so that `@prettier/sync` — the same API with
+ * the awaits taken out — satisfies it too. Everything here is awaited either
+ * way, and a formatter is allowed to be synchronous: `ValFormatter` says so.
+ */
+export type PrettierLike = {
+    format(source: string, options: PrettierLikeConfig & {
+        filepath: string;
+    }): Promise<string> | string;
+    resolveConfig(filePath: string): Promise<PrettierLikeConfig | null> | PrettierLikeConfig | null;
+    getFileInfo(filePath: string, options: {
+        ignorePath: string[];
+    }): Promise<{
+        ignored: boolean;
+    }> | {
+        ignored: boolean;
+    };
+};
+/**
+ * A {@link ValFormatter} that formats the way the project itself does.
+ *
+ * ONE implementation, for every writer of source files Val has: the Studio and
+ * the dev server (`initValServer`), an agent (`initValMcp`) and
+ * `val validate --fix`. They used to disagree — the CLI called
+ * `prettier.format(code, { filepath })` on its own behalf, and `format` does
+ * not read `.prettierrc`; only `resolveConfig`, `getFileInfo` and the prettier
+ * CLI do. `filepath` there selects the PARSER and nothing else, so the output
+ * was valid TypeScript in prettier's default style rather than the project's:
+ * a two-line content fix arriving as a whole-file rewrite, and a red `format`
+ * job in any repo that checks formatting in CI.
+ *
+ * ```ts
+ * import prettier from "prettier";
+ * import { createPrettierFormatter } from "@valbuild/next/server";
+ *
+ * initValServer(valModules, config, {
+ *   draftMode,
+ *   formatter: createPrettierFormatter(prettier, { projectRoot: process.cwd() }),
+ * });
+ * ```
+ *
+ * `projectRoot` is what a project-relative path is resolved against, and is
+ * therefore also where `.prettierignore` is looked for. Prettier's own config
+ * search walks UP from the resolved file, so a monorepo package with its own
+ * `.prettierrc` is found without being named here.
+ *
+ * Two decisions worth knowing:
+ *
+ * - **`.prettierignore` is honoured; `.gitignore` is not.** The prettier CLI
+ *   consults both, but only one of them is a statement about formatting — a
+ *   file is gitignored for reasons that have nothing to do with style, and the
+ *   only files reaching this function are ones Val itself just wrote.
+ * - **No config found is not an error.** `resolveConfig` returns `null` and
+ *   the file is formatted with prettier's defaults, which is what a project
+ *   without a config has asked for.
+ */
+export declare function createPrettierFormatter(prettier: PrettierLike, options: {
+    projectRoot: string;
+}): ValFormatter;

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

@@ -29,6 +29,8 @@ export { getValidationErrorFileRef } from "./getValidationErrorFileRef.js";
 export { checkRemoteRef, downloadFileFromRemote, getCachedRemoteFileDir, getCachedRemoteFilePath, } from "./checkRemoteRef.js";
 export { hasRemoteFileSchema } from "@valbuild/core";
 export { getFileExt } from "./getFileExt.js";
+export { createPrettierFormatter } from "./createPrettierFormatter.js";
+export type { PrettierLike, PrettierLikeConfig, ValFormatter, } from "./createPrettierFormatter.js";
 export { evalValConfigFile, findAndEvalValConfigFile, } from "./evalValConfigFile.js";
 export { startValLogin, awaitValLoginConfirmation, persistPersonalAccessToken, ValLoginError, DEFAULT_LOGIN_HOST, DEFAULT_LOGIN_EXPIRES_IN_SECONDS, DEFAULT_LOGIN_POLL_INTERVAL_SECONDS, } from "./login.js";
 export type { ValLoginErrorCode, ValLoginResult, ValDeviceAuthorization, } from "./login.js";
@@ -42,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
           }
         };
@@ -15311,12 +15380,62 @@ function createValApiRouter(route, valServerPromise, convert) {
         }
         query = queryRes.data;
       }
-      const res = await endpointImpl({
-        body: bodyRes.data,
-        cookies: cookiesRes.data,
-        query,
-        path
-      });
+
+      /*
+       * A throw from an endpoint is Val's to report, not the framework's.
+       *
+       * Nothing here used to catch, so an endpoint that threw left the router
+       * entirely and became whatever the host does with an unhandled error --
+       * and on TanStack Start that is h3, which replaces the message with the
+       * literal string "HTTPError" and drops the stack. Its `debug` and
+       * `silent` options are not reachable from out here: `requestHandler`
+       * calls `toResponse(value, event)` with no config, and the default is
+       * `{}`. So the body a caller got was
+       * `{"status":500,"unhandled":true,"message":"HTTPError"}` -- the same
+       * five words for a missing project, a bad cookie secret and a module
+       * that failed to link -- with the real cause only on the server's
+       * console.
+       *
+       * That is survivable where the console is readable. It is not in a
+       * Cloudflare Dynamic Worker, whose `console` reaches no tail stream: a
+       * link error in a lazily imported chunk (`does not provide an export
+       * named 'getSerovalPlugins'`) showed up as an unreadable 500 on
+       * `/authorize` and nowhere else at all.
+       *
+       * So every endpoint's throw becomes Val's own 500 envelope, which the
+       * Studio already renders and `curl` already prints. The route and method
+       * are named because a message rarely says which endpoint it came from.
+       *
+       * The MESSAGE travels and the STACK does not. The message is the whole
+       * diagnostic value -- the line above names the package, the chunk and
+       * the export -- while a stack is a walk through somebody's bundle, and
+       * `/authorize` and `/enable` are reachable without a session. So the
+       * stack goes to the console, where a host that can read one will find
+       * it, and the body carries what a caller can act on.
+       */
+      let res;
+      try {
+        res = await endpointImpl({
+          body: bodyRes.data,
+          cookies: cookiesRes.data,
+          query,
+          path
+        });
+      } catch (err) {
+        const error = err instanceof Error ? err : new Error(String(err));
+        console.error(`Val: ${method} ${route} threw: ${error.message}`, error.stack);
+        return {
+          status: 500,
+          json: {
+            message: `Val: ${method} ${route} failed: ${error.message}`,
+            details: {
+              route,
+              method,
+              error: error.message
+            }
+          }
+        };
+      }
       if (res.status === 500) {
         var _res$json;
         return {
@@ -17246,6 +17365,123 @@ function validateMetadata(actualMetadata, expectedMetadata) {
   };
 }
 
+/**
+ * What Val calls to format a file it has just written.
+ *
+ * The same shape `initValServer`, `initValMcp` and `ValOps` take as their
+ * `formatter` option. The path is the file's path INSIDE the project — a
+ * `ModuleFilePath` such as `/content/page.val.ts`, or a `*.val.json` entry
+ * beside it — never an absolute path on disk, because the writers that call it
+ * (`ValOps.prepare`, the CLI's `--fix`) only ever know a module by that path.
+ */
+
+/**
+ * Prettier's options, as far as this file is concerned.
+ *
+ * Deliberately opaque: this file never reads an option, it only carries the
+ * bag from `resolveConfig` to `format`. Naming the real `Options` here would
+ * make it a compile error to build `@valbuild/server` in a project that has no
+ * prettier installed, which is most of them — prettier is a dependency the app
+ * opts into, so it is passed IN rather than imported.
+ */
+
+/**
+ * `prettier`, as this file wants it.
+ *
+ * Structural for the same reason `SharpLike` in `@valbuild/mcp` is: a type-only
+ * import of a package that is not installed is still a compile error, and this
+ * package has to typecheck without prettier. `createPrettierFormatter.test.ts`
+ * asserts the real library against this type so the structural description
+ * cannot drift away from it unnoticed.
+ *
+ * Every result is `T | Promise<T>` so that `@prettier/sync` — the same API with
+ * the awaits taken out — satisfies it too. Everything here is awaited either
+ * way, and a formatter is allowed to be synchronous: `ValFormatter` says so.
+ */
+
+/**
+ * Resolve a path Val handed us against the project.
+ *
+ * Val's writers pass a project-relative path (`/content/page.val.ts`), and
+ * prettier needs a real one — both to find the `.prettierrc` that governs the
+ * file and to match it against `.prettierignore`. An absolute path that is
+ * already inside the project is taken as it comes, so a caller that happens to
+ * hold a real path is not mangled into `<root>/<root>/...`.
+ */
+function resolveAgainstProject(projectRoot, filePath) {
+  if (path__namespace["default"].isAbsolute(filePath)) {
+    const relative = path__namespace["default"].relative(projectRoot, filePath);
+    if (relative && !relative.startsWith("..") && !path__namespace["default"].isAbsolute(relative)) {
+      return filePath;
+    }
+  }
+  return path__namespace["default"].join(projectRoot, filePath);
+}
+
+/**
+ * A {@link ValFormatter} that formats the way the project itself does.
+ *
+ * ONE implementation, for every writer of source files Val has: the Studio and
+ * the dev server (`initValServer`), an agent (`initValMcp`) and
+ * `val validate --fix`. They used to disagree — the CLI called
+ * `prettier.format(code, { filepath })` on its own behalf, and `format` does
+ * not read `.prettierrc`; only `resolveConfig`, `getFileInfo` and the prettier
+ * CLI do. `filepath` there selects the PARSER and nothing else, so the output
+ * was valid TypeScript in prettier's default style rather than the project's:
+ * a two-line content fix arriving as a whole-file rewrite, and a red `format`
+ * job in any repo that checks formatting in CI.
+ *
+ * ```ts
+ * import prettier from "prettier";
+ * import { createPrettierFormatter } from "@valbuild/next/server";
+ *
+ * initValServer(valModules, config, {
+ *   draftMode,
+ *   formatter: createPrettierFormatter(prettier, { projectRoot: process.cwd() }),
+ * });
+ * ```
+ *
+ * `projectRoot` is what a project-relative path is resolved against, and is
+ * therefore also where `.prettierignore` is looked for. Prettier's own config
+ * search walks UP from the resolved file, so a monorepo package with its own
+ * `.prettierrc` is found without being named here.
+ *
+ * Two decisions worth knowing:
+ *
+ * - **`.prettierignore` is honoured; `.gitignore` is not.** The prettier CLI
+ *   consults both, but only one of them is a statement about formatting — a
+ *   file is gitignored for reasons that have nothing to do with style, and the
+ *   only files reaching this function are ones Val itself just wrote.
+ * - **No config found is not an error.** `resolveConfig` returns `null` and
+ *   the file is formatted with prettier's defaults, which is what a project
+ *   without a config has asked for.
+ */
+function createPrettierFormatter(prettier, options) {
+  const projectRoot = path__namespace["default"].resolve(options.projectRoot);
+  // One array, built once: prettier reads and caches the ignore file itself, so
+  // this is only here to avoid rebuilding the path per file.
+  const ignorePath = [path__namespace["default"].join(projectRoot, ".prettierignore")];
+  return async (code, filePath) => {
+    const absoluteFilePath = resolveAgainstProject(projectRoot, filePath);
+    const {
+      ignored
+    } = await prettier.getFileInfo(absoluteFilePath, {
+      ignorePath
+    });
+    if (ignored) {
+      return code;
+    }
+    // `resolveConfig` applies the `overrides` that match this file and caches
+    // per directory, so calling it per file is cheap even on a project-wide
+    // `--fix`. `filepath` is still required: it is what picks the parser.
+    const config = await prettier.resolveConfig(absoluteFilePath);
+    return prettier.format(code, {
+      ...config,
+      filepath: absoluteFilePath
+    });
+  };
+}
+
 /**
  * NOTE: this is intentionally NOT `SharedValConfig` from `@valbuild/shared`.
  * That schema requires `files.directory` to be exactly `/public/val`, whereas
@@ -17854,6 +18090,7 @@ exports.createDefaultValFSHost = createDefaultValFSHost;
 exports.createFixPatch = createFixPatch;
 exports.createJsonEntryPathMap = createJsonEntryPathMap;
 exports.createModulePathMap = createModulePathMap;
+exports.createPrettierFormatter = createPrettierFormatter;
 exports.createService = createService;
 exports.createValApiRouter = createValApiRouter;
 exports.createValModuleFileInspector = createValModuleFileInspector;
@@ -17871,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;