@valbuild/server 0.143.1 → 0.144.1

package/CHANGELOG.md

@@ -1,5 +1,28 @@
 # @valbuild/server
 
+## 0.144.1
+
+### Patch Changes
+
+- [#824](https://github.com/valbuild/val/pull/824) [`a641bb0`](https://github.com/valbuild/val/commit/a641bb0286756339252c53e9230d766c23fcccc6) Thanks [@freekh](https://github.com/freekh)! - `.jsonValues()` entries saved in a proposal now show at the proposal's address. Before, the page kept showing the entry as it was when the site was last built, and the Studio there showed every entry of a saved `.jsonValues()` module as empty.
+
+## 0.144.0
+
+### Patch Changes
+
+- [#788](https://github.com/valbuild/val/pull/788) [`a84271c`](https://github.com/valbuild/val/commit/a84271c534822071c1e428cf9990602459682d25) Thanks [@freekh](https://github.com/freekh)! - Fixes to `npx val validate` for `s.imagedir()` and `s.filedir()`, and the `s.image(galleryVal)` / `s.file(filesVal)` fields that use them:
+
+  - **`--fix` now updates every field that uses an uploaded image or file.** When `--fix` moves an entry of an `s.imagedir(dir).remote()` or `s.filedir(dir, options).remote()` to Val Remote, the entry's key changes from the local path to the remote URL. Fields that held the old path were left pointing at it, and reported "The gallery does not have an image at …" with nothing to fix it. Now `s.image(galleryVal)` and `s.file(filesVal)` fields, and images in rich text (`s.richtext({ img: s.image(galleryVal) })`), are updated in the same run. The VS Code extension's "upload to Val Remote" updates them in the same edit, including fields inside `.jsonValues()` entries, which live in their own `*.val.json` files.
+  - **A field that uses an image or file from a `.remote()` gallery is no longer reported as "Expected local image, but found remote".** The gallery decides whether its files are on Val Remote; the field only has to name a file the gallery has. Before, `--fix` would download the file and point the field at a path the gallery did not have.
+  - **Images uploaded through a field into a `.remote()` gallery.** When you upload an image through an `s.image(galleryVal)` field in Val Studio, the field stores the remote URL and the gallery stores the image under its local path. Validation now accepts this, and `useVal` / `fetchVal` now fill in the image's `width`, `height` and `mimeType` from the gallery for it, as they do for every other gallery image.
+  - **Errors in a gallery's keys are reported.** A remote URL in a gallery that is not `.remote()`, a remote URL that is not valid, or one outside the gallery's `dir` was silently ignored by `npx val validate`. It is now reported as an error. `--fix` does not change it: you decide whether the key or the gallery's options are wrong.
+  - **A file is no longer reported as valid when it still has an error.** When `--fix` fixed one error in a file and another error was left, the file could be printed as "✔ valid".
+
+- Updated dependencies [[`a84271c`](https://github.com/valbuild/val/commit/a84271c534822071c1e428cf9990602459682d25), [`860ab2b`](https://github.com/valbuild/val/commit/860ab2b87333daf95a48215b0e4a1b44f441c878)]:
+  - @valbuild/core@0.144.0
+  - @valbuild/shared@0.144.0
+  - @valbuild/ui@0.144.0
+
 ## 0.143.1
 
 ### Patch Changes

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

@@ -51,6 +51,13 @@ export type ValOpsOptions = {
      * the next save's prepare -- starts from it, and the SHAs describe it.
      */
     snapshotSources?: Sources;
+    /**
+     * The `.jsonValues()` entries the same snapshot saved, by module and key:
+     * their content is in their own files, not in {@link snapshotSources}, which
+     * holds markers. The baseline those entries are read from, as a save in
+     * this instance would leave them (`proposalJsonEntries` in `./proposal`).
+     */
+    snapshotJsonEntries?: Map<ModuleFilePath, Map<string, JSONValue>>;
 };
 export declare abstract class ValOps {
     private readonly valModules;
@@ -101,7 +108,9 @@ export declare abstract class ValOps {
      * unlike a module source there is nothing to re-extract, because the memo was
      * never holding the content in the first place.
      *
-     * `null` for an entry the commit deleted.
+     * `deleted` for an entry the commit deleted: tagged, not `null`, because an
+     * entry's content may itself be JSON `null` (a nullable item), and a saved
+     * `null` read back as "deleted" would report the entry missing.
      *
      * Never cleared: it describes what is on disk. A host rebuild makes a new
      * instance, which is the right reset. Bounded by the project's entry count,

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

@@ -194,7 +194,35 @@ export declare function handleVideoMetadata(ctx: FixHandlerContext): Promise<Fix
 export declare function handleRemoteFileUpload(ctx: FixHandlerContext): Promise<FixHandlerResult>;
 export declare function handleRemoteGalleryFileUpload(ctx: FixHandlerContext): Promise<FixHandlerResult>;
 export declare function handleRemoteFileDownload(ctx: FixHandlerContext): Promise<FixHandlerResult>;
+/**
+ * `image:check-remote` / `file:check-remote`: core's "Remote image was not
+ * checked." — emitted for EVERY remote value of an `s.image().remote()` /
+ * `s.file().remote()`, wrong or not, because core cannot read the bytes or the
+ * ref's validation hash. It is a request to look, not a finding, so there is
+ * nothing to report here: `createFixPatch` does the looking (`checkRemoteRef`)
+ * and returns an error only for a ref that is actually wrong, with a fix where
+ * the ref only needs rewriting.
+ *
+ * So these stay a hand-off. Reporting core's message here instead would put an
+ * error on every remote image in a project, which is what the language server
+ * learned to stop doing (`mediaChecks.ts`).
+ */
 export declare function handleRemoteFileCheck(): Promise<FixHandlerResult>;
+/**
+ * `images:check-remote` / `files:check-remote`: a gallery key that is wrong as
+ * a key — a remote URL in a gallery that is not `.remote()`, a ref that does
+ * not parse, one outside the gallery's directory (`validateMediaKey` in core).
+ *
+ * Unlike the singular codes, core emits these only when something IS wrong,
+ * and its message says what. There is nothing to look up and nothing to move,
+ * so it is reported as it is, for a person: only they know whether the key or
+ * the gallery's options are the mistake. It used to share the singular codes'
+ * handler, which hands off to `createFixPatch` — and that has no branch for a
+ * gallery key, so the error vanished and the module was reported valid.
+ *
+ * The same answer as `videos:check-remote`.
+ */
+export declare function handleGalleryCheckRemote(ctx: Pick<FixHandlerContext, "validationError">): Promise<FixHandlerResult>;
 export declare function handleUniqueFolderCheck(ctx: FixHandlerContext): Promise<FixHandlerResult>;
 export declare function handleCheckAllFiles(ctx: FixHandlerContext): Promise<FixHandlerResult>;
 export declare function handleJsonValuesExtractEntry(ctx: FixHandlerContext): Promise<FixHandlerResult>;

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

@@ -2,7 +2,7 @@ export { createService, Service } from "./Service.js";
 export { defineExternal, ok, err, isExternalResult, EXTERNAL_RESULT, } from "./externalRecords.js";
 export type { AdapterFor, BoundExternalRecord, ExternalAuthor, ExternalBuilder, ExternalCtx, ExternalDefinition, ExternalFile, ExternalIssue, ExternalKeyPage, ExternalRecords, ExternalResult, ExternalSearchHit, ExternalSearchPage, ExternalSort, ItemOfModule, ReadonlyRecordHasNoWrites, Returns, } from "./externalRecords.js";
 export { createValApiRouter, createValServer, safeReadGit } from "./ValRouter.js";
-export { proposalFromEnv, proposalSnapshot } from "./proposal.js";
+export { proposalFromEnv, proposalSnapshot, proposalSnapshotForReaders, } from "./proposal.js";
 export type { ValProposal } from "./proposal.js";
 export { initHandlerOptions, createValOps } from "./valServerConfig.js";
 export { resolveRemoteFileAuth } from "./valServerConfig.js";

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

@@ -1,4 +1,5 @@
 import type { Json, ModuleFilePath } from "@valbuild/core";
+import type { JSONValue } from "@valbuild/core/patch";
 /**
  * A proposal this server runs at the address of: an editor-managed branch of
  * the project's content, served from its own copy of the content the
@@ -70,3 +71,30 @@ export declare function proposalFromEnv(env: {
  * what the snapshot holds.
  */
 export declare function proposalSnapshot(proposal: Pick<ValProposal, "modules">): Record<ModuleFilePath, Json>;
+/**
+ * The `.jsonValues()` entries the proposal saved, by module and key.
+ *
+ * An entry's content is not in its module's Source -- that holds a marker per
+ * entry -- but in the entry's own `*.val.json`, and a save writes that file:
+ * it reaches the proposal's address as saved TEXT ({@link ValProposal.files}),
+ * not as Source. So the snapshot alone shows the build's entries. This is the
+ * other half: each saved `*.val.json`, read as the entry its module names.
+ *
+ * Which entry a file is comes from the module's `.val.ts`, whose
+ * `c.json(() => import("..."))` thunks name the files -- the saved text if
+ * the save rewrote it, else the build's own (`projectSource`). An entry whose
+ * module cannot be read that way is left to the build, as before: this adds
+ * what it can find and never fails the address.
+ */
+export declare function proposalJsonEntries(proposal: Pick<ValProposal, "modules" | "files">, projectSource?: Record<string, string>): Map<ModuleFilePath, Map<string, JSONValue>>;
+/**
+ * The snapshot as a page reads it: {@link proposalSnapshot}, with each saved
+ * `.jsonValues()` entry's content in place of its marker -- the shape a draft
+ * already has, where the entries it edits hold content and the rest are
+ * markers the readers resolve from the build. See {@link proposalJsonEntries}.
+ *
+ * For the readers only. Val's own server keeps the markers
+ * ({@link proposalSnapshot}): its patching works on them, and it takes the
+ * saved entries separately.
+ */
+export declare function proposalSnapshotForReaders(proposal: Pick<ValProposal, "modules" | "files">, projectSource?: Record<string, string>): Record<ModuleFilePath, Json>;

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

@@ -52,10 +52,11 @@ export declare function filesNamedByVideoFields(service: VideoFieldService, opti
 /**
  * The patches that point every `s.video(set)` field at a set entry's new key.
  *
- * One `add` on each field's `path`, so the description, poster, times and
- * captions beside it are never rewritten. A field of another set, or of no
- * set, is left alone even when its path is the same string: it names its own
- * file.
+ * The same walk an image or file collection's rename uses
+ * (`collectionReferencePatches`): one `add` on each field's `path`, so the
+ * description, poster, times and captions beside it are never rewritten, and
+ * a field of another set, or of no set, is left alone even when its path is
+ * the same string — it names its own file.
  */
 export declare function videosetReferencePatches(service: VideoFieldService, setModuleFilePath: ModuleFilePath, renamed: Record<string, string>): Promise<ModulePatch[]>;
 /**