@valbuild/server 0.134.1 → 0.136.0

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
           }
         };
@@ -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;

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
           }
         };
@@ -15277,12 +15346,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 +17331,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 +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, 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 };