@valbuild/server 0.123.2 → 0.124.0

package/CHANGELOG.md

@@ -1,5 +1,74 @@
 # @valbuild/server
 
+## 0.124.0
+
+### Minor Changes
+
+- [#639](https://github.com/valbuild/val/pull/639) [`ad7fff4`](https://github.com/valbuild/val/commit/ad7fff4cc8cea98c506cf7ff9b4e8d6e5ffa4055) Thanks [@freekh](https://github.com/freekh)! - Show `.jsonValues()` entries in the history pane
+
+  A `.jsonValues()` record keeps each entry's content in its own `*.val.json`
+  file; the module's own content is just markers pointing at them. The history
+  pane had no way to fetch those files for a past commit, so every entry rendered
+  as an **empty field** — which reads as "the author left this blank", about
+  content that was simply stored somewhere else.
+
+  Entries now load in the history pane the same way they load in the Studio: one
+  at a time, when you open one. A commit with a thousand support pages costs
+  nothing until you look at one of them.
+
+  An entry that cannot be read says so instead of rendering blank — including the
+  case where the key did not exist yet at that commit, which is a real answer
+  rather than an error.
+
+### Patch Changes
+
+- [#639](https://github.com/valbuild/val/pull/639) [`ad7fff4`](https://github.com/valbuild/val/commit/ad7fff4cc8cea98c506cf7ff9b4e8d6e5ffa4055) Thanks [@freekh](https://github.com/freekh)! - Require a session to read a file from history
+
+  `GET /api/val/history/files` served a file at a given commit to anyone who
+  asked. It followed the reasoning of `/api/val/files`, which is deliberately
+  open — and neither half of that reasoning applies to it:
+
+  - `/files` stands on `patch_id` being an unguessable UUID. A **commit sha is
+    published** — `git log`, the GitHub UI, every pull request — so it is no
+    substitute for a credential.
+  - `/files` also _cannot_ require auth: draft images are fetched by the app's own
+    backend during Next image optimisation, with no cookies to send. Nothing
+    fetches history files server-side; both callers are the Studio, in a browser
+    that already holds the session.
+
+  So history files now require a session. `/files` is unchanged, and the reason
+  the two differ is written down in `architecture/media.md` so it is not "fixed"
+  in either direction later.
+
+  No action needed: the Studio sends its session cookie automatically.
+
+- Updated dependencies [[`5674237`](https://github.com/valbuild/val/commit/56742371a75b4fdcbff8b1afccff8fcc1ebf8078), [`ad7fff4`](https://github.com/valbuild/val/commit/ad7fff4cc8cea98c506cf7ff9b4e8d6e5ffa4055), [`ad7fff4`](https://github.com/valbuild/val/commit/ad7fff4cc8cea98c506cf7ff9b4e8d6e5ffa4055), [`aa89fc2`](https://github.com/valbuild/val/commit/aa89fc26de7028b3c5a1666b99afc03b39e92769)]:
+  - @valbuild/ui@0.124.0
+  - @valbuild/shared@0.124.0
+  - @valbuild/core@0.124.0
+
+## 0.123.3
+
+### Patch Changes
+
+- [#623](https://github.com/valbuild/val/pull/623) [`4c9369b`](https://github.com/valbuild/val/commit/4c9369bad3f17e96868262e78a4f47361d85319e) Thanks [@freekh](https://github.com/freekh)! - Add the editor quick fix for a `.jsonValues()` entry written inline: **Val: move entry into its own .val.json**.
+
+  The language server already reported the problem — "Entry '…' is written inline … Run 'val validate --fix' to move it" — but offered no way to act on it, so the only remedy was to leave the editor and run the CLI. It now offers a quick fix that creates the `*.val.json` with the entry's content and rewrites the `.val.ts` to `c.json(() => import("./…"))`, in one undoable step.
+
+  The fix is computed from the same code `val validate --fix` runs, so the two write the same files, and it is computed against the buffer you are looking at rather than what is on disk — an unsaved module can be fixed without saving first. It refuses, rather than overwriting, when a file or an unsaved buffer already occupies the target path.
+
+  Requires an editor that honours file creation inside a workspace edit; VS Code does. In an editor that does not announce it, no action is offered rather than one that would rewrite the module to import a file that never got created.
+
+- [#621](https://github.com/valbuild/val/pull/621) [`fb1baff`](https://github.com/valbuild/val/commit/fb1baffead5228d8a86a51af65178b88738d5a64) Thanks [@freekh](https://github.com/freekh)! - Fix `.jsonValues()` validation being silently skipped when the CLI is run through `npx` / `pnpm dlx`.
+
+  `npx @valbuild/cli validate` reported a `.jsonValues()` module whose entries were still written inline in the `.val.ts` as **valid**, and `--fix` moved nothing into `*.val.json`. Running the CLI installed in the project (`./node_modules/.bin/val validate --fix`) worked, which made this look like a schema or path problem rather than a tooling one.
+
+  The cause: the project's `*.val.ts` are evaluated with a `require` rooted at the project, so their schemas come from the project's `@valbuild/core`, while `npx`/`dlx` runs the CLI's own second copy. The entry check guarded on `schema instanceof RecordSchema`, which is false across those two copies, and it failed open — the whole check returned "no errors". The guard is now structural, so it holds whichever copy built the schema. If you gate CI on `npx @valbuild/cli validate`, that gate was green for the wrong reason.
+
+- Updated dependencies [[`accf4f8`](https://github.com/valbuild/val/commit/accf4f852fe3400d762cc14e80316da741a69a9a), [`356eb11`](https://github.com/valbuild/val/commit/356eb11b5f6a0a02dfec80580c6fccac75d28402), [`aef45ce`](https://github.com/valbuild/val/commit/aef45ce3ef269f1b6221de44a56df0f6a0d9dbbd)]:
+  - @valbuild/shared@0.123.3
+  - @valbuild/ui@0.123.3
+
 ## 0.123.2
 
 ### Patch Changes

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

@@ -486,6 +486,17 @@ export declare abstract class ValOps {
     abstract getCommitAffectedFiles(commitSha: string): Promise<result.Result<AffectedFile[], HistoryError>>;
     /** One file's bytes as they were at one commit. */
     abstract getFileAtCommit(commitSha: string, filePath: string, remote: boolean): Promise<result.Result<Buffer, HistoryError>>;
+    /**
+     * Where a module lives in the REPOSITORY, as `getFileAtCommit` wants it.
+     *
+     * A `ModuleFilePath` is project-relative (`/app/page.val.ts`); a git path is
+     * repository-relative and carries the project root in front of it
+     * (`examples/next/app/page.val.ts`). Only the ops know that root, which is
+     * why this is here rather than computed by the history functions - and why a
+     * history function that needs to read a module's own file at a commit has to
+     * ask instead of concatenating.
+     */
+    abstract gitPathOfModule(moduleFilePath: ModuleFilePath): result.Result<string, HistoryError>;
 }
 export type WithGenericError<T extends Record<string, unknown>> = (T & {
     error?: undefined;

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

@@ -172,4 +172,5 @@ export declare class ValOpsFS extends ValOps {
     }, HistoryError>>;
     getCommitAffectedFiles(): Promise<result.Result<AffectedFile[], HistoryError>>;
     getFileAtCommit(): Promise<result.Result<Buffer, HistoryError>>;
+    gitPathOfModule(_moduleFilePath: ModuleFilePath): result.Result<string, HistoryError>;
 }

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

@@ -310,6 +310,15 @@ export declare class ValOpsHttp extends ValOps {
         complete: boolean;
     }, HistoryError>>;
     getCommitAffectedFiles(commitSha: string): Promise<result.Result<AffectedFile[], HistoryError>>;
+    /**
+     * `root` in front, and never a doubled or missing slash.
+     *
+     * `root` is "" for a project at the repository root and something like
+     * `examples/next` otherwise; a ModuleFilePath always starts with "/". Joining
+     * them by hand at each call site is how one of these ends up with "//" in the
+     * middle, which GitHub answers with a 404 that reads like a missing file.
+     */
+    gitPathOfModule(moduleFilePath: ModuleFilePath): result.Result<string, HistoryError>;
     getFileAtCommit(commitSha: string, filePath: string, remote: boolean): Promise<result.Result<Buffer, HistoryError>>;
 }
 export {};

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

@@ -1,17 +1,61 @@
 import type { Json, ModuleFilePath } from "@valbuild/core";
+import { result } from "@valbuild/core/fp";
 import { ValSourceFileHandler } from "./ValSourceFileHandler.js";
+/**
+ * The two files an extraction touches, as text — nothing written yet.
+ *
+ * Both paths are project-relative in the `ModuleFilePath` style (a leading
+ * slash), because that is what the callers already hold and what
+ * {@link getNewJsonEntryPaths} derives. Join them onto the project root to get
+ * somewhere to write.
+ */
+export type JsonValuesEntryExtraction = {
+    /** The `*.val.json` to CREATE. It must not already exist — see the note below. */
+    jsonPath: string;
+    jsonContent: string;
+    /** The `.val.ts` to rewrite, and its complete new text. */
+    valTsPath: string;
+    valTsContent: string;
+};
+/**
+ * Works out what moving ONE inline `.jsonValues()` entry into its own
+ * `*.val.json` would change, without changing anything.
+ *
+ * This is the whole fix for `jsonValues:extract-entry`, minus the writing. It
+ * is split out because the two callers cannot share a way of applying it: the
+ * CLI writes both files ({@link extractJsonValuesEntry}), while the editor has
+ * to hand the same two changes back as a `WorkspaceEdit` so they go through the
+ * undo stack and respect an unsaved buffer. Anything that lived in only one of
+ * those would be a fix that behaves differently depending on where it was
+ * invoked from, which is exactly the drift `codeActions.ts` exists to prevent.
+ *
+ * It does NOT check whether `jsonPath` already exists: that needs a filesystem,
+ * and the editor's answer ("is there a buffer or a file here?") is not the
+ * CLI's. Every caller must check before writing — overwriting an unrelated file
+ * is not a fix.
+ *
+ * Root-only, like the rest of the `.jsonValues()` machinery: the entry is looked
+ * up in the module's root record/router object literal.
+ */
+export declare function planJsonValuesEntryExtraction({ moduleFilePath, entryKey, content, valTsPath, valTsText, }: {
+    moduleFilePath: ModuleFilePath;
+    entryKey: string;
+    /** The entry's value, as it is written inline in the `.val.ts`. */
+    content: Json;
+    /** Where the `.val.ts` lives, for error messages. */
+    valTsPath: string;
+    /** Its text — the editor's version of it, where there is an editor. */
+    valTsText: string;
+}): result.Result<JsonValuesEntryExtraction, string>;
 /**
  * Moves ONE `.jsonValues()` entry that was written inline in the `.val.ts` into
  * its own `*.val.json`, replacing the inline value with
  * `c.json(() => import("./<key>.val.json"))`.
  *
- * This is the fix for the `jsonValues:extract-entry` validation error. It is not
- * expressible as a patch (a patch edits one `.val.ts` and cannot create the
+ * The `val validate --fix` half of {@link planJsonValuesEntryExtraction}. It is
+ * not expressible as a patch (a patch edits one `.val.ts` and cannot create the
  * backing JSON file), so it writes both files directly — JSON first, so a
  * failure part-way through never leaves the module pointing at a file that does
  * not exist.
- *
- * Root-only, like the rest of the `.jsonValues()` machinery: the entry is looked
- * up in the module's root record/router object literal.
  */
 export declare function extractJsonValuesEntry(moduleFilePath: ModuleFilePath, rootDir: string, entryKey: string, content: Json, sourceFileHandler: ValSourceFileHandler): void;

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

@@ -36,7 +36,8 @@ export { createModulePathMap, createJsonEntryPathMap, getModulePathRange, } from
 export { findJsonEntryFilePath } from "./jsonEntryLocation.js";
 export { classifyJsonValuesOp, rebaseContentOp } from "./patch/jsonValuesPatch.js";
 export type { JsonValuesOpClass } from "./patch/jsonValuesPatch.js";
-export { extractJsonValuesEntry } from "./extractJsonValuesEntry.js";
+export { extractJsonValuesEntry, planJsonValuesEntryExtraction, } from "./extractJsonValuesEntry.js";
+export type { JsonValuesEntryExtraction } from "./extractJsonValuesEntry.js";
 export type { ModulePathMap } from "./modulePathMap.js";
 export { ValOpsFS } from "./ValOpsFS.js";
 export { ValOpsHttp } from "./ValOpsHttp.js";