@valbuild/language-server 0.116.0 → 0.117.1

package/CHANGELOG.md

@@ -0,0 +1,68 @@
+# @valbuild/language-server
+
+## 0.117.1
+
+### Patch Changes
+
+- Updated dependencies []:
+  - @valbuild/server@0.117.1
+
+## 0.117.0
+
+### Patch Changes
+
+- [#581](https://github.com/valbuild/val/pull/581) [`d94a40f`](https://github.com/valbuild/val/commit/d94a40f8bd11027636d183e293aced820b6f341f) Thanks [@freekh](https://github.com/freekh)! - Images no longer show a validation warning in the editor when nothing is wrong
+  with them.
+
+  Every `s.image()` carrying width, height or a mime type used to be marked in VS
+  Code with "Found image metadata, but it could not be validated", whether or not
+  the metadata was correct — so the warning sat on every image in the project and
+  never went away, not even after applying its own quick fix.
+
+  That message was never a finding. `@valbuild/core` cannot read files, so it
+  cannot answer whether stored dimensions match the image, and it hands the
+  question on as an `image:check-metadata` fix instead. `val validate` has always
+  resolved that by reading the file and comparing; the language server now does
+  the same, and reports only what actually disagrees:
+
+  ```
+  Image width is incorrect! Found: 800. Expected: 944
+  ```
+
+  An image whose metadata is right gets nothing. A missing `width`, `height` or
+  `mimeType` is reported, as is a stale one, with the quick fix still offered. A
+  file that is not on disk is still reported as a missing file rather than as a
+  metadata problem.
+
+  The four messages involved say what they mean now, in the editor and in
+  `val validate` alike:
+
+  - "Image metadata has not been checked against the file." (was "Found image
+    metadata, but it could not be validated. An image must have a width (positive
+    number), a height (positive number) and a mime type." — which described a
+    check that never ran)
+  - "Image metadata is missing: width, height and mimeType." (was "Could not
+    validate Image metadata.")
+  - "File mimeType has not been checked against the file." (was "Found mimeType,
+    but it could not be validated.")
+  - "File metadata is missing: mimeType." (was "Missing File mimeType.")
+
+  Also fixes an `s.file()` whose `mimeType` is missing: it reported "Mime type and
+  file extension not matching. Mime type is 'undefined'" with no fix attached, so
+  no quick fix was offered and the `file:add-metadata` case was unreachable. It
+  now reports the missing mime type and offers to add it.
+
+- [#579](https://github.com/valbuild/val/pull/579) [`b2812ae`](https://github.com/valbuild/val/commit/b2812ae4ee03e005ecead3365f49c625e536f94d) Thanks [@freekh](https://github.com/freekh)! - Every release now ships a changelog. Each package's `CHANGELOG.md` records what
+  changed under the version that shipped it — with a link to the pull request, the
+  commit and the author — and the same entry becomes the body of the GitHub
+  Release for the tag. The file is included in the npm tarball, so it is also
+  readable from an installed copy.
+
+  Up to now those changelogs were generated empty, and the GitHub Releases with
+  them, so there was no record of what any given version contained. Releases from
+  this one on have one; earlier versions stay blank.
+
+- Updated dependencies [[`fca3efa`](https://github.com/valbuild/val/commit/fca3efa389e2817401f55ea3dd184af7c611b807), [`d94a40f`](https://github.com/valbuild/val/commit/d94a40f8bd11027636d183e293aced820b6f341f), [`b2812ae`](https://github.com/valbuild/val/commit/b2812ae4ee03e005ecead3365f49c625e536f94d)]:
+  - @valbuild/server@0.117.0
+  - @valbuild/core@0.117.0
+  - @valbuild/shared@0.117.0

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

@@ -1,6 +1,7 @@
 import { type ModuleFilePath, type SourcePath, type ValidationError, type ValidationFix } from "@valbuild/core";
 import { type SchemaSourceSnapshot } from "@valbuild/shared/internal";
 import { Diagnostic, DiagnosticSeverity } from "vscode-languageserver";
+import { type MediaMetadataVerdict } from "./mediaMetadataChecks.js";
 import type { ValModuleContent } from "./ValProject.js";
 /** Marks diagnostics as ours, so a client can filter on it. */
 export declare const VAL_DIAGNOSTIC_SOURCE = "val";
@@ -73,7 +74,7 @@ export declare function severityFor({ code, fixes, }: {
     code: ValDiagnosticCode;
     fixes?: ValidationFix[];
 }): DiagnosticSeverity;
-export declare function createValDiagnostics({ moduleFilePath, content, text, valRoot, snapshot, galleryChecks, }: {
+export declare function createValDiagnostics({ moduleFilePath, content, text, valRoot, snapshot, galleryChecks, mediaMetadataChecks, }: {
     moduleFilePath: ModuleFilePath;
     content: ValModuleContent;
     /** Current text of the module, as the editor sees it. */
@@ -101,6 +102,15 @@ export declare function createValDiagnostics({ moduleFilePath, content, text, va
      * the caller that can adjudicate them is the one that has a `Service`.
      */
     galleryChecks?: ReadonlyMap<string, GalleryCheckVerdict>;
+    /**
+     * Verdicts for the media metadata placeholders core emits unconditionally,
+     * from {@link resolveMediaMetadataChecks}. Without it the placeholders are
+     * dropped, for the same reason the gallery ones are: core reports
+     * `image:check-metadata` on every `s.image()` that carries metadata whether
+     * or not anything is wrong, so publishing them raw puts a permanent warning
+     * on every image in the project.
+     */
+    mediaMetadataChecks?: ReadonlyMap<string, MediaMetadataVerdict>;
 }): Diagnostic[];
 /**
  * Diagnostic for a project that could not be evaluated at all.

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

@@ -0,0 +1,105 @@
+/**
+ * Adjudicating the media metadata placeholders core emits unconditionally.
+ *
+ * `ImageSchema.validate` cannot read bytes, so it never answers "does the
+ * stored width/height/mimeType match the file". It defers instead: any
+ * `s.image()` carrying metadata gets an `image:check-metadata` error whether
+ * or not anything is wrong (`packages/core/src/schema/image.ts`), and
+ * `s.file()` does the same with `file:check-metadata`.
+ *
+ * `val validate` resolves those by running the fix handler and then
+ * `createFixPatch` in report mode, which compares each field against the file
+ * and returns one error per field that disagrees. The Studio cannot do that at
+ * all -- a browser has no filesystem -- so it drops them wholesale
+ * (`partitionValidationErrors` in `@valbuild/shared`).
+ *
+ * An editor is in the CLI's position, not the browser's, and publishing the
+ * placeholders raw put a permanent warning on every image in the project. So
+ * they are adjudicated here, by the same comparison `val validate` makes, and
+ * only a real disagreement is shown.
+ */
+import { type SourcePath, type ValidationError, type ValidationFix } from "@valbuild/core";
+import type { ValModuleContent } from "./ValProject.js";
+/** One field of a media value that disagrees with the file behind it. */
+export type MediaMetadataFinding = {
+    message: string;
+    /** The placeholder's own fixes, so the quick fix and severity survive. */
+    fixes?: ValidationFix[];
+    /** The placeholder's `value`, which `createFixPatch` reads. */
+    value?: unknown;
+};
+/**
+ * The verdict on one placeholder. Empty means the metadata agrees with the
+ * file and nothing should be published.
+ */
+export type MediaMetadataVerdict = MediaMetadataFinding[];
+/**
+ * Whether this error is the unconditional deferral rather than a real finding.
+ *
+ * This is the whole difficulty of the change. `image:check-metadata` is
+ * attached to FIVE different image errors, and only the last is a placeholder:
+ *
+ *  1. `Invalid mime type format`            -- `accept` set, mimeType has no `/`
+ *  2. `Mime type mismatch`                  -- `accept` set and not satisfied
+ *  3. `Could not determine mime type from file extension`
+ *  4. `Mime type and file extension not matching`
+ *  5. the fall-through deferral
+ *
+ * The first four are real: they are about the mime type disagreeing with the
+ * schema or with the filename, neither of which reading the file can settle.
+ * Adjudicating one of them would find the stored metadata matches the bytes and
+ * drop a genuine error -- so they have to be told apart before any file is read.
+ *
+ * There is no flag on `ValidationError` saying which is which, so the four
+ * conditions are re-derived here from the same inputs core used. They are
+ * transcribed from `ImageSchema.executeValidate`, in its order, and
+ * `mediaMetadataChecks.test.ts` drives real core through all five cases to
+ * check that this agrees with it. If core grows a sixth condition, that test is
+ * what catches it.
+ *
+ * `FileSchema` needs none of this: its four equivalent errors carry no `fixes`
+ * at all, so `file:check-metadata` is unambiguous. The test pins that too.
+ */
+export declare function isDeferredMediaMetadataCheck({ error, schema, }: {
+    /**
+     * The error to classify. Its `value` is the media value core validated, and
+     * so is what core's conditions are re-derived from -- the same value
+     * `createFixPatch` compares against the file, so the classification and the
+     * comparison cannot disagree about which image they are talking about.
+     */
+    error: ValidationError;
+    /** The resolved serialized schema, which is where `accept` lives. */
+    schema: unknown;
+}): boolean;
+/**
+ * {@link isDeferredMediaMetadataCheck} for an error in a module, resolving the
+ * schema it needs.
+ *
+ * Both the adjudicator and `createValDiagnostics` have to make the same call,
+ * on the same inputs -- one to decide what to adjudicate, the other to decide
+ * what to publish -- so it lives here rather than being written out twice.
+ */
+export declare function isDeferredMediaMetadataCheckAt({ sourcePath, error, content, }: {
+    sourcePath: string;
+    error: ValidationError;
+    content: ValModuleContent;
+}): boolean;
+/**
+ * Adjudicate every deferred metadata placeholder in `validation`.
+ *
+ * Async, and therefore separate from `createValDiagnostics`, which stays
+ * synchronous so it can be tested without a project -- the same split
+ * `resolveGalleryChecks` uses. The caller runs this first and passes the
+ * result in.
+ */
+export declare function resolveMediaMetadataChecks({ validation, content, valRoot, remoteHost, }: {
+    validation: Record<SourcePath, ValidationError[]>;
+    content: ValModuleContent;
+    valRoot: string;
+    remoteHost?: string;
+}): Promise<Map<string, MediaMetadataVerdict>>;
+/**
+ * Key for one placeholder. A value can in principle carry more than one, so
+ * the fix names are part of the key -- as they are for the gallery checks.
+ */
+export declare function mediaMetadataCheckKey(sourcePath: string, error: ValidationError): string;

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

@@ -857,6 +857,314 @@ function traverseObjectLiteral(node, sourceFile) {
   return map;
 }
 
+/**
+ * Adjudicating the media metadata placeholders core emits unconditionally.
+ *
+ * `ImageSchema.validate` cannot read bytes, so it never answers "does the
+ * stored width/height/mimeType match the file". It defers instead: any
+ * `s.image()` carrying metadata gets an `image:check-metadata` error whether
+ * or not anything is wrong (`packages/core/src/schema/image.ts`), and
+ * `s.file()` does the same with `file:check-metadata`.
+ *
+ * `val validate` resolves those by running the fix handler and then
+ * `createFixPatch` in report mode, which compares each field against the file
+ * and returns one error per field that disagrees. The Studio cannot do that at
+ * all -- a browser has no filesystem -- so it drops them wholesale
+ * (`partitionValidationErrors` in `@valbuild/shared`).
+ *
+ * An editor is in the CLI's position, not the browser's, and publishing the
+ * placeholders raw put a permanent warning on every image in the project. So
+ * they are adjudicated here, by the same comparison `val validate` makes, and
+ * only a real disagreement is shown.
+ */
+/**
+ * The fixes that carry an unconditional metadata placeholder.
+ *
+ * `*:add-metadata` is deliberately absent: it is emitted only when every
+ * metadata field is missing, which needs no adjudication -- there is nothing
+ * stored to compare, and the error stands on its own.
+ */
+const METADATA_CHECK_FIXES = ["image:check-metadata", "file:check-metadata"];
+
+/** One field of a media value that disagrees with the file behind it. */
+
+/**
+ * The verdict on one placeholder. Empty means the metadata agrees with the
+ * file and nothing should be published.
+ */
+
+/**
+ * Whether this error is the unconditional deferral rather than a real finding.
+ *
+ * This is the whole difficulty of the change. `image:check-metadata` is
+ * attached to FIVE different image errors, and only the last is a placeholder:
+ *
+ *  1. `Invalid mime type format`            -- `accept` set, mimeType has no `/`
+ *  2. `Mime type mismatch`                  -- `accept` set and not satisfied
+ *  3. `Could not determine mime type from file extension`
+ *  4. `Mime type and file extension not matching`
+ *  5. the fall-through deferral
+ *
+ * The first four are real: they are about the mime type disagreeing with the
+ * schema or with the filename, neither of which reading the file can settle.
+ * Adjudicating one of them would find the stored metadata matches the bytes and
+ * drop a genuine error -- so they have to be told apart before any file is read.
+ *
+ * There is no flag on `ValidationError` saying which is which, so the four
+ * conditions are re-derived here from the same inputs core used. They are
+ * transcribed from `ImageSchema.executeValidate`, in its order, and
+ * `mediaMetadataChecks.test.ts` drives real core through all five cases to
+ * check that this agrees with it. If core grows a sixth condition, that test is
+ * what catches it.
+ *
+ * `FileSchema` needs none of this: its four equivalent errors carry no `fixes`
+ * at all, so `file:check-metadata` is unambiguous. The test pins that too.
+ */
+function isDeferredMediaMetadataCheck({
+  error,
+  schema
+}) {
+  const fixes = error.fixes ?? [];
+  if (!fixes.some(fix => METADATA_CHECK_FIXES.includes(fix))) {
+    return false;
+  }
+  if (fixes.includes("file:check-metadata")) {
+    return true;
+  }
+  const value = mediaValueOf(error.value);
+  if (typeof value?.path !== "string") {
+    // Nothing to re-derive the conditions from. Keep the error: claiming an
+    // image is fine on no evidence is the worse failure.
+    return false;
+  }
+  const accept = acceptOf(schema);
+  // Core reads `src.mimeType ?? ""`, and every condition below is guarded on
+  // it being non-empty, so an absent mimeType passes all four.
+  const mimeType = typeof value.mimeType === "string" ? value.mimeType : "";
+  if (accept && mimeType && !mimeType.includes("/")) {
+    return false;
+  }
+  if (accept && mimeType && mimeType.includes("/") && !core.Internal.mimeTypeMatchesAccept(mimeType, accept)) {
+    return false;
+  }
+  const fileMimeType = core.Internal.filenameToMimeType(value.path);
+  if (!fileMimeType) {
+    return false;
+  }
+  if (mimeType && fileMimeType !== mimeType) {
+    return false;
+  }
+  return true;
+}
+
+/**
+ * {@link isDeferredMediaMetadataCheck} for an error in a module, resolving the
+ * schema it needs.
+ *
+ * Both the adjudicator and `createValDiagnostics` have to make the same call,
+ * on the same inputs -- one to decide what to adjudicate, the other to decide
+ * what to publish -- so it lives here rather than being written out twice.
+ */
+function isDeferredMediaMetadataCheckAt({
+  sourcePath,
+  error,
+  content
+}) {
+  return isDeferredMediaMetadataCheck({
+    error,
+    schema: resolveSchemaAt$1(sourcePath, content)
+  });
+}
+
+/**
+ * Adjudicate every deferred metadata placeholder in `validation`.
+ *
+ * Async, and therefore separate from `createValDiagnostics`, which stays
+ * synchronous so it can be tested without a project -- the same split
+ * `resolveGalleryChecks` uses. The caller runs this first and passes the
+ * result in.
+ */
+async function resolveMediaMetadataChecks({
+  validation,
+  content,
+  valRoot,
+  remoteHost = process.env.VAL_REMOTE_HOST || core.DEFAULT_VAL_REMOTE_HOST
+}) {
+  const verdicts = new Map();
+  for (const [sourcePath, errors] of Object.entries(validation)) {
+    for (const error of errors) {
+      if (!isDeferredMediaMetadataCheckAt({
+        sourcePath,
+        error,
+        content
+      })) {
+        continue;
+      }
+      const key = mediaMetadataCheckKey(sourcePath, error);
+      try {
+        verdicts.set(key, await adjudicate({
+          sourcePath,
+          error,
+          content,
+          valRoot,
+          remoteHost
+        }));
+      } catch {
+        // This runs inside `validate`, which publishes NOTHING if it throws --
+        // one bad image would silently clear every Val diagnostic in the file.
+        // Keep the placeholder rather than claiming the metadata is fine.
+        verdicts.set(key, keep(error));
+      }
+    }
+  }
+  return verdicts;
+}
+
+/**
+ * Key for one placeholder. A value can in principle carry more than one, so
+ * the fix names are part of the key -- as they are for the gallery checks.
+ */
+function mediaMetadataCheckKey(sourcePath, error) {
+  return `${sourcePath}|${(error.fixes ?? []).join(",")}`;
+}
+
+/** Keeping the placeholder: what to publish when we learned nothing. */
+function keep(error) {
+  return [{
+    message: error.message,
+    ...(error.fixes ? {
+      fixes: error.fixes
+    } : {}),
+    ...(error.value !== undefined ? {
+      value: error.value
+    } : {})
+  }];
+}
+
+/**
+ * What `createFixPatch` says about one placeholder, in report mode.
+ *
+ * `val validate` runs the fix handler first and then `createFixPatch`, but for
+ * these four fixes the handler is `handleFileMetadata`, whose whole job is the
+ * precondition "the ref resolves and the file is on disk". That precondition is
+ * checked directly here instead, for two reasons:
+ *
+ *  - `createValDiagnostics` already reports a missing file as
+ *    `val/file-not-found`, which is a better diagnostic than a metadata
+ *    mismatch and is produced before this verdict is consulted.
+ *  - `handleFileMetadata` resolves the source path through the module, and that
+ *    throws outright for a `.jsonValues()` entry ("Cannot resolve path into a
+ *    jsonValues entry until its content is loaded") -- so routing through it
+ *    would leave every entry-backed image stuck on the placeholder.
+ *
+ * The comparison itself is still `createFixPatch`, unchanged, which is the
+ * parity that matters: the editor's wording is the CLI's wording because it is
+ * the CLI's code -- including for bytes it cannot measure, where it reports
+ * what `val validate` reports rather than a second opinion of our own.
+ *
+ * `createFixPatch` reads and decodes the image itself, so this is one file read
+ * per media field per validation pass, and nothing here should add another.
+ */
+async function adjudicate({
+  sourcePath,
+  error,
+  content,
+  valRoot,
+  remoteHost
+}) {
+  const ref = mediaValueOf(error.value)?.path;
+  if (typeof ref !== "string") {
+    return keep(error);
+  }
+  // A remote ref is a URL and is not expected on disk. Core does not emit these
+  // fixes for one, but a stale ref should not be reported as a local mismatch.
+  if (core.Internal.remote.splitRemoteRef(ref).status === "success") {
+    return keep(error);
+  }
+  if (!fs__default["default"].existsSync(path__default["default"].join(valRoot, ref))) {
+    // Reported as `val/file-not-found` instead; keeping the placeholder here
+    // means this verdict never has the last word on a file that is not there.
+    return keep(error);
+  }
+  let fixed;
+  try {
+    fixed = await server.createFixPatch({
+      projectRoot: valRoot,
+      remoteHost
+    },
+    // `false`: this is a question, not a fix. Asking for the patch would have
+    // createFixPatch read and rewrite files behind the editor's back.
+    false, sourcePath, error, {}, content.source, content.schema);
+  } catch {
+    return keep(error);
+  }
+  return (fixed?.remainingErrors ?? []).map(remaining => ({
+    message: remaining.message,
+    // `createFixPatch` clears `fixes` on the per-field errors it reports, but
+    // the fix is still available and still the remedy -- it is what the
+    // placeholder was asking for. Carrying the placeholder's own fixes is what
+    // keeps the "update image metadata" quick fix offered, and the diagnostic
+    // a Warning rather than an Error.
+    ...(error.fixes ? {
+      fixes: error.fixes
+    } : {}),
+    ...(error.value !== undefined ? {
+      value: error.value
+    } : {})
+  }));
+}
+
+/**
+ * The `accept` a media schema declares, if any.
+ *
+ * Read from the serialized schema (`SerializedImageSchema.options`) rather
+ * than from a schema instance: this runs against what `Service.get` returns.
+ */
+function acceptOf(schema) {
+  if (typeof schema !== "object" || schema === null || !("options" in schema)) {
+    return undefined;
+  }
+  const {
+    options
+  } = schema;
+  if (typeof options !== "object" || options === null || !("accept" in options)) {
+    return undefined;
+  }
+  const {
+    accept
+  } = options;
+  return typeof accept === "string" ? accept : undefined;
+}
+
+/** A media value, read as a plain record. */
+function mediaValueOf(value) {
+  if (typeof value !== "object" || value === null || Array.isArray(value)) {
+    return undefined;
+  }
+  return value;
+}
+
+/**
+ * The serialized schema at a source path.
+ *
+ * Only the schema is taken from resolution -- `accept` is not on the value, and
+ * the value itself comes from the error. Same call `missingFileRef` in
+ * `diagnostics.ts` makes, and it can fail the same ways (a schema that failed
+ * to serialize, a path that no longer resolves), so failure is not an error
+ * here, just an absence.
+ */
+function resolveSchemaAt$1(sourcePath, content) {
+  if (!content.source || !content.schema) {
+    return undefined;
+  }
+  try {
+    const [, modulePath] = core.Internal.splitModuleFilePathAndModulePath(sourcePath);
+    return core.Internal.resolvePath(modulePath, content.source, content.schema).schema;
+  } catch {
+    return undefined;
+  }
+}
+
 /** Marks diagnostics as ours, so a client can filter on it. */
 const VAL_DIAGNOSTIC_SOURCE = "val";
 
@@ -948,7 +1256,8 @@ function createValDiagnostics({
   text,
   valRoot,
   snapshot,
-  galleryChecks
+  galleryChecks,
+  mediaMetadataChecks
 }) {
   if (content.errors === false) {
     return [];
@@ -1020,6 +1329,33 @@ function createValDiagnostics({
         continue;
       }
 
+      // An unconditional media metadata placeholder: core reports
+      // `image:check-metadata` on every `s.image()` carrying metadata, whether
+      // or not it disagrees with the file. Show only what the adjudication
+      // actually found, and nothing when it found nothing. Deliberately after
+      // the missing-file branch above, so a deleted file is still reported as
+      // `val/file-not-found` rather than as a metadata mismatch.
+      if (isDeferredMediaMetadataCheckAt({
+        sourcePath,
+        error,
+        content
+      })) {
+        const verdict = mediaMetadataChecks?.get(mediaMetadataCheckKey(sourcePath, error));
+        for (const finding of verdict ?? []) {
+          diagnostics.push(build(rangeOf(sourcePath, modulePathMap), finding.message, {
+            code: "val/validation",
+            sourcePath,
+            ...(finding.fixes ? {
+              fixes: finding.fixes
+            } : {}),
+            ...(finding.value !== undefined ? {
+              value: finding.value
+            } : {})
+          }));
+        }
+        continue;
+      }
+
       // A gallery-backed field whose path the gallery does not track. Core
       // reports it with no fix because the remedy is elsewhere; giving it its
       // own code is what lets the editor offer the two remedies.
@@ -2110,6 +2446,17 @@ async function createValCodeActions({
   remoteHost = process.env.VAL_REMOTE_HOST || core.DEFAULT_VAL_REMOTE_HOST
 }) {
   const actions = [];
+  /**
+   * Fixes already offered, as `<fix target>|<fix>`.
+   *
+   * One problem can be reported as several diagnostics that share a fix: a
+   * stale image reports its width and its height separately, and a gallery
+   * check reports one finding per entry. The fix is the same patch each time --
+   * `createFixPatch` corrects every field, and the gallery branch walks every
+   * entry -- so without this the editor offers the identical "Val: update image
+   * metadata" twice, and recomputes it (re-reading the image) to do so.
+   */
+  const offered = new Set();
   for (const diagnostic of diagnostics) {
     const data = diagnostic.data;
     if (!data?.fixes?.length) {
@@ -2148,6 +2495,10 @@ async function createValCodeActions({
       if (!isLocalFix(fix)) {
         continue;
       }
+      const fixTarget = data.fixSourcePath ?? data.sourcePath;
+      if (offered.has(`${fixTarget}|${fix}`)) {
+        continue;
+      }
       const fixEdit = await computeFixEdit({
         document,
         // A gallery check is reported on the entry but fixed against the record
@@ -2169,6 +2520,7 @@ async function createValCodeActions({
       if (!fixEdit) {
         continue;
       }
+      offered.add(`${fixTarget}|${fix}`);
       actions.push(vscodeLanguageserver.CodeAction.create(FIX_TITLES[fix] ?? `Val: ${fix}`,
       // Not always `document.uri`: a fix inside a `.jsonValues()` entry
       // edits the entry's own `*.val.json`, which is a different file from
@@ -3530,6 +3882,14 @@ function createValLanguageServer(connection) {
           runFixHandler: args => activeProject.runFixHandler(args)
         })
       }) : undefined;
+      // Core also defers "does this image's stored metadata match its file",
+      // reporting it on every `s.image()` that carries any metadata. Same
+      // treatment: adjudicate with the fix machinery before showing anything.
+      const mediaMetadataChecks = result.content.errors !== false && result.content.errors.validation ? await resolveMediaMetadataChecks({
+        validation: result.content.errors.validation,
+        content: result.content,
+        valRoot: activeProject.valRoot
+      }) : undefined;
       const diagnostics = createValDiagnostics({
         moduleFilePath,
         content: result.content,
@@ -3540,6 +3900,9 @@ function createValLanguageServer(connection) {
         } : {}),
         ...(galleryChecks ? {
           galleryChecks
+        } : {}),
+        ...(mediaMetadataChecks ? {
+          mediaMetadataChecks
         } : {})
       });
       const unregistered = findMissingModuleDiagnostic(project.valRoot, moduleFilePath, readOpenDocument);