@valbuild/server 0.134.0 → 0.135.0

package/CHANGELOG.md

@@ -1,5 +1,73 @@
 # @valbuild/server
 
+## 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
+
+- Updated dependencies [[`821e789`](https://github.com/valbuild/val/commit/821e789c1af47510af5d23eb96384ff78ddd7646)]:
+  - @valbuild/shared@0.134.1
+  - @valbuild/ui@0.134.0
+
 ## 0.134.0
 
 ### Patch Changes

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";

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

@@ -15311,12 +15311,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 +17296,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 +18021,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;

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

@@ -15311,12 +15311,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 +17296,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 +18021,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;

package/dist/valbuild-server.esm.js

@@ -15277,12 +15277,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 {
@@ -17212,6 +17262,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__default.isAbsolute(filePath)) {
+    const relative = path__default.relative(projectRoot, filePath);
+    if (relative && !relative.startsWith("..") && !path__default.isAbsolute(relative)) {
+      return filePath;
+    }
+  }
+  return path__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__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__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
@@ -17794,4 +17961,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, 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, 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,10 +16,11 @@
     "./package.json": "./package.json"
   },
   "types": "dist/valbuild-server.cjs.d.ts",
-  "version": "0.134.0",
+  "version": "0.135.0",
   "devDependencies": {
     "@prettier/sync": "^0.6.1",
-    "@types/jest": "^30.0.0"
+    "@types/jest": "^30.0.0",
+    "prettier": "~3.8.5"
   },
   "dependencies": {
     "chokidar": "^5.0.0",
@@ -30,7 +31,7 @@
     "zod": "^4.4.3",
     "zod-validation-error": "^5.0.0",
     "@valbuild/core": "0.134.0",
-    "@valbuild/shared": "0.134.0",
+    "@valbuild/shared": "0.134.1",
     "@valbuild/ui": "0.134.0"
   },
   "engines": {