@valbuild/shared 0.123.3 → 0.124.0

package/CHANGELOG.md

@@ -1,5 +1,50 @@
 # @valbuild/shared
 
+## 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 [[`aa89fc2`](https://github.com/valbuild/val/commit/aa89fc26de7028b3c5a1666b99afc03b39e92769)]:
+  - @valbuild/core@0.124.0
+
 ## 0.123.3
 
 ### Patch Changes

package/dist/declarations/src/internal/ApiRoutes.d.ts

@@ -1329,6 +1329,80 @@ export declare const Api: {
      * actually mounts. A file at a fixed commit cannot change, so the response is
      * immutable and the browser's own cache handles flipping between commits.
      */
+    /**
+     * One `.jsonValues()` entry's content, as it was at a commit.
+     *
+     * The history pane's counterpart to `/json`. A `.jsonValues()` record's
+     * source is only `{_type:"json"}` markers - the content is per entry, fetched
+     * on demand - so without this the commit pane rendered every entry as an
+     * empty field, which is a claim that the author left it blank.
+     *
+     * One entry per request, deliberately: the store fetches an entry when
+     * something reads inside it, so a batch would mean guessing which entries the
+     * pane is about to show. Authenticated for the same reasons as
+     * `/history/files` below.
+     */
+    "/history/json": {
+        GET: {
+            req: {
+                query: {
+                    commit_sha: z.ZodPipe<z.ZodArray<z.ZodString>, z.ZodTransform<string, string[]>>;
+                    path: z.ZodPipe<z.ZodArray<z.ZodString>, z.ZodTransform<string, string[]>>;
+                    key: z.ZodPipe<z.ZodArray<z.ZodString>, z.ZodTransform<string, string[]>>;
+                };
+                cookies: {
+                    val_session: z.ZodOptional<z.ZodString>;
+                };
+            };
+            res: z.ZodUnion<readonly [z.ZodObject<{
+                status: z.ZodLiteral<401>;
+                json: z.ZodObject<{
+                    message: z.ZodString;
+                }, z.core.$strip>;
+            }, z.core.$strip>, z.ZodObject<{
+                status: z.ZodLiteral<404>;
+                json: z.ZodObject<{
+                    message: z.ZodString;
+                }, z.core.$strip>;
+            }, z.core.$strip>, z.ZodObject<{
+                status: z.ZodLiteral<400>;
+                json: z.ZodIntersection<z.ZodObject<{
+                    message: z.ZodString;
+                }, z.core.$strip>, z.ZodObject<{
+                    kind: z.ZodOptional<z.ZodString>;
+                }, z.core.$strip>>;
+            }, z.core.$strip>, z.ZodObject<{
+                status: z.ZodLiteral<500>;
+                json: z.ZodIntersection<z.ZodObject<{
+                    message: z.ZodString;
+                }, z.core.$strip>, z.ZodObject<{
+                    kind: z.ZodOptional<z.ZodString>;
+                }, z.core.$strip>>;
+            }, z.core.$strip>, z.ZodObject<{
+                status: z.ZodLiteral<200>;
+                json: z.ZodObject<{
+                    path: z.ZodString & z.ZodType<ModuleFilePath, string, z.core.$ZodTypeInternals<ModuleFilePath, string>>;
+                    key: z.ZodString;
+                    content: z.ZodUnknown;
+                }, z.core.$strip>;
+            }, z.core.$strip>]>;
+        };
+    };
+    /**
+     * A binary file as it was at a commit.
+     *
+     * AUTHENTICATED, unlike `/files` below - and the difference is not an
+     * oversight in either direction. See the comment on `/files`: what makes it
+     * safe to leave open is that a `patch_id` is an unguessable UUID, and what
+     * makes leaving it open NECESSARY is that a draft image is fetched by the
+     * app's own backend during Next image optimisation, with no cookies.
+     *
+     * Neither holds here. A commit sha is published - `git log`, the GitHub UI,
+     * every PR - so it is not a secret to stand in for a credential. And nothing
+     * fetches these server-side: they are read by the Studio, in a browser that
+     * has the session cookie, for the history pane and for staging a restore.
+     * So this one asks.
+     */
     "/history/files": {
         GET: {
             req: {
@@ -1337,6 +1411,9 @@ export declare const Api: {
                     path: z.ZodPipe<z.ZodArray<z.ZodString>, z.ZodTransform<string, string[]>>;
                     remote: z.ZodOptional<z.ZodPipe<z.ZodArray<z.ZodString>, z.ZodTransform<string, string[]>>>;
                 };
+                cookies: {
+                    val_session: z.ZodOptional<z.ZodString>;
+                };
             };
             res: z.ZodUnion<readonly [z.ZodObject<{
                 status: z.ZodLiteral<401>;

package/internal/dist/valbuild-shared-internal.cjs.dev.js

@@ -2463,6 +2463,66 @@ var Api = {
    * actually mounts. A file at a fixed commit cannot change, so the response is
    * immutable and the browser's own cache handles flipping between commits.
    */
+  /**
+   * One `.jsonValues()` entry's content, as it was at a commit.
+   *
+   * The history pane's counterpart to `/json`. A `.jsonValues()` record's
+   * source is only `{_type:"json"}` markers - the content is per entry, fetched
+   * on demand - so without this the commit pane rendered every entry as an
+   * empty field, which is a claim that the author left it blank.
+   *
+   * One entry per request, deliberately: the store fetches an entry when
+   * something reads inside it, so a batch would mean guessing which entries the
+   * pane is about to show. Authenticated for the same reasons as
+   * `/history/files` below.
+   */
+  "/history/json": {
+    GET: {
+      req: {
+        query: {
+          commit_sha: onlyOneStringQueryParam,
+          path: onlyOneStringQueryParam,
+          key: onlyOneStringQueryParam
+        },
+        cookies: {
+          val_session: zod.z.string().optional()
+        }
+      },
+      res: zod.z.union([unauthorizedResponse, notFoundResponse, zod.z.object({
+        status: zod.z.literal(400),
+        json: GenericError.and(zod.z.object({
+          kind: zod.z.string().optional()
+        }))
+      }), zod.z.object({
+        status: zod.z.literal(500),
+        json: GenericError.and(zod.z.object({
+          kind: zod.z.string().optional()
+        }))
+      }), zod.z.object({
+        status: zod.z.literal(200),
+        json: zod.z.object({
+          path: ModuleFilePath,
+          key: zod.z.string(),
+          content: zod.z.unknown()
+        })
+      })])
+    }
+  },
+  /**
+   * A binary file as it was at a commit.
+   *
+   * AUTHENTICATED, unlike `/files` below - and the difference is not an
+   * oversight in either direction. See the comment on `/files`: what makes it
+   * safe to leave open is that a `patch_id` is an unguessable UUID, and what
+   * makes leaving it open NECESSARY is that a draft image is fetched by the
+   * app's own backend during Next image optimisation, with no cookies.
+   *
+   * Neither holds here. A commit sha is published - `git log`, the GitHub UI,
+   * every PR - so it is not a secret to stand in for a credential. And nothing
+   * fetches these server-side: they are read by the Studio, in a browser that
+   * has the session cookie, for the history pane and for staging a restore.
+   * So this one asks.
+   */
   "/history/files": {
     GET: {
       req: {
@@ -2470,6 +2530,9 @@ var Api = {
           commit_sha: onlyOneStringQueryParam,
           path: onlyOneStringQueryParam,
           remote: onlyOneStringQueryParam.optional()
+        },
+        cookies: {
+          val_session: zod.z.string().optional()
         }
       },
       res: zod.z.union([unauthorizedResponse, notFoundResponse, zod.z.object({

package/internal/dist/valbuild-shared-internal.cjs.prod.js

@@ -2463,6 +2463,66 @@ var Api = {
    * actually mounts. A file at a fixed commit cannot change, so the response is
    * immutable and the browser's own cache handles flipping between commits.
    */
+  /**
+   * One `.jsonValues()` entry's content, as it was at a commit.
+   *
+   * The history pane's counterpart to `/json`. A `.jsonValues()` record's
+   * source is only `{_type:"json"}` markers - the content is per entry, fetched
+   * on demand - so without this the commit pane rendered every entry as an
+   * empty field, which is a claim that the author left it blank.
+   *
+   * One entry per request, deliberately: the store fetches an entry when
+   * something reads inside it, so a batch would mean guessing which entries the
+   * pane is about to show. Authenticated for the same reasons as
+   * `/history/files` below.
+   */
+  "/history/json": {
+    GET: {
+      req: {
+        query: {
+          commit_sha: onlyOneStringQueryParam,
+          path: onlyOneStringQueryParam,
+          key: onlyOneStringQueryParam
+        },
+        cookies: {
+          val_session: zod.z.string().optional()
+        }
+      },
+      res: zod.z.union([unauthorizedResponse, notFoundResponse, zod.z.object({
+        status: zod.z.literal(400),
+        json: GenericError.and(zod.z.object({
+          kind: zod.z.string().optional()
+        }))
+      }), zod.z.object({
+        status: zod.z.literal(500),
+        json: GenericError.and(zod.z.object({
+          kind: zod.z.string().optional()
+        }))
+      }), zod.z.object({
+        status: zod.z.literal(200),
+        json: zod.z.object({
+          path: ModuleFilePath,
+          key: zod.z.string(),
+          content: zod.z.unknown()
+        })
+      })])
+    }
+  },
+  /**
+   * A binary file as it was at a commit.
+   *
+   * AUTHENTICATED, unlike `/files` below - and the difference is not an
+   * oversight in either direction. See the comment on `/files`: what makes it
+   * safe to leave open is that a `patch_id` is an unguessable UUID, and what
+   * makes leaving it open NECESSARY is that a draft image is fetched by the
+   * app's own backend during Next image optimisation, with no cookies.
+   *
+   * Neither holds here. A commit sha is published - `git log`, the GitHub UI,
+   * every PR - so it is not a secret to stand in for a credential. And nothing
+   * fetches these server-side: they are read by the Studio, in a browser that
+   * has the session cookie, for the history pane and for staging a restore.
+   * So this one asks.
+   */
   "/history/files": {
     GET: {
       req: {
@@ -2470,6 +2530,9 @@ var Api = {
           commit_sha: onlyOneStringQueryParam,
           path: onlyOneStringQueryParam,
           remote: onlyOneStringQueryParam.optional()
+        },
+        cookies: {
+          val_session: zod.z.string().optional()
         }
       },
       res: zod.z.union([unauthorizedResponse, notFoundResponse, zod.z.object({

package/internal/dist/valbuild-shared-internal.esm.js

@@ -2456,6 +2456,66 @@ var Api = {
    * actually mounts. A file at a fixed commit cannot change, so the response is
    * immutable and the browser's own cache handles flipping between commits.
    */
+  /**
+   * One `.jsonValues()` entry's content, as it was at a commit.
+   *
+   * The history pane's counterpart to `/json`. A `.jsonValues()` record's
+   * source is only `{_type:"json"}` markers - the content is per entry, fetched
+   * on demand - so without this the commit pane rendered every entry as an
+   * empty field, which is a claim that the author left it blank.
+   *
+   * One entry per request, deliberately: the store fetches an entry when
+   * something reads inside it, so a batch would mean guessing which entries the
+   * pane is about to show. Authenticated for the same reasons as
+   * `/history/files` below.
+   */
+  "/history/json": {
+    GET: {
+      req: {
+        query: {
+          commit_sha: onlyOneStringQueryParam,
+          path: onlyOneStringQueryParam,
+          key: onlyOneStringQueryParam
+        },
+        cookies: {
+          val_session: z.string().optional()
+        }
+      },
+      res: z.union([unauthorizedResponse, notFoundResponse, z.object({
+        status: z.literal(400),
+        json: GenericError.and(z.object({
+          kind: z.string().optional()
+        }))
+      }), z.object({
+        status: z.literal(500),
+        json: GenericError.and(z.object({
+          kind: z.string().optional()
+        }))
+      }), z.object({
+        status: z.literal(200),
+        json: z.object({
+          path: ModuleFilePath,
+          key: z.string(),
+          content: z.unknown()
+        })
+      })])
+    }
+  },
+  /**
+   * A binary file as it was at a commit.
+   *
+   * AUTHENTICATED, unlike `/files` below - and the difference is not an
+   * oversight in either direction. See the comment on `/files`: what makes it
+   * safe to leave open is that a `patch_id` is an unguessable UUID, and what
+   * makes leaving it open NECESSARY is that a draft image is fetched by the
+   * app's own backend during Next image optimisation, with no cookies.
+   *
+   * Neither holds here. A commit sha is published - `git log`, the GitHub UI,
+   * every PR - so it is not a secret to stand in for a credential. And nothing
+   * fetches these server-side: they are read by the Studio, in a browser that
+   * has the session cookie, for the history pane and for staging a restore.
+   * So this one asks.
+   */
   "/history/files": {
     GET: {
       req: {
@@ -2463,6 +2523,9 @@ var Api = {
           commit_sha: onlyOneStringQueryParam,
           path: onlyOneStringQueryParam,
           remote: onlyOneStringQueryParam.optional()
+        },
+        cookies: {
+          val_session: z.string().optional()
         }
       },
       res: z.union([unauthorizedResponse, notFoundResponse, z.object({

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@valbuild/shared",
-  "version": "0.123.3",
+  "version": "0.124.0",
   "private": false,
   "description": "Val shared types and utilities",
   "repository": {
@@ -37,7 +37,7 @@
     "flexsearch": "^0.8.212",
     "zod": "^4.4.3",
     "zod-validation-error": "^5.0.0",
-    "@valbuild/core": "0.121.0"
+    "@valbuild/core": "0.124.0"
   },
   "files": [
     "CHANGELOG.md",