@valbuild/language-server 0.124.0 → 0.126.0

package/CHANGELOG.md

@@ -1,5 +1,120 @@
 # @valbuild/language-server
 
+## 0.126.0
+
+### Patch Changes
+
+- Updated dependencies [[`5bfd630`](https://github.com/valbuild/val/commit/5bfd630b63dee2189e238f20fe72ecc5537160f7), [`ccbcda6`](https://github.com/valbuild/val/commit/ccbcda60b3e3c465071229ae1ba28ac735483e63), [`f2fe70d`](https://github.com/valbuild/val/commit/f2fe70dab2b65000dfaf289f09c70b4a8291467a), [`5c18c99`](https://github.com/valbuild/val/commit/5c18c99ecc84651f82123481fc042063db953833), [`171208a`](https://github.com/valbuild/val/commit/171208a20177e68ed5a8b1a6fdaabfe893a6aa5f)]:
+  - @valbuild/shared@0.126.0
+  - @valbuild/server@0.126.0
+  - @valbuild/core@0.126.0
+
+## 0.125.0
+
+### Patch Changes
+
+- [#645](https://github.com/valbuild/val/pull/645) [`22f78b4`](https://github.com/valbuild/val/commit/22f78b471fd18e542f518f72b75bd472d7c3dc52) Thanks [@freekh](https://github.com/freekh)! - The editor no longer warns "Remote image was not checked." on every remote image
+  and file.
+
+  That message is a placeholder: core cannot reach the content host, so
+  `s.image().remote()` reports it unconditionally and leaves the real check to
+  whoever can make it. `val validate` makes it and prints nothing when the ref is
+  sound; the language server was publishing the placeholder raw, so every remote
+  image in a project carried a permanent warning that no quick fix could clear.
+
+  It is now adjudicated the same way the metadata placeholder already was — by
+  running Val's own check — so a valid ref reports nothing, and a ref that no
+  longer matches the bytes behind it reports what the CLI reports:
+
+  ```
+  Remote ref: https://remote.val.build/file/p/…/renaming.gif is not valid. Use the --fix flag to fix this issue.
+  ```
+
+  Nothing is downloaded for a ref that still adds up; only a stale one is fetched,
+  into the same `.val/remote-file-cache` the CLI uses.
+
+- [#638](https://github.com/valbuild/val/pull/638) [`c390397`](https://github.com/valbuild/val/commit/c390397cb5e203eb1bedae3a6fab15726e850b90) Thanks [@freekh](https://github.com/freekh)! - Val now runs on TanStack Start.
+
+  `@valbuild/tanstack` is a new package with everything `@valbuild/next` has: Val
+  Studio at `/val`, the on-page overlay and canvas, draft mode, the client hooks,
+  server-side content reads, images, and the MCP tools.
+
+  ```sh
+  npm install @valbuild/tanstack
+  ```
+
+  ```ts
+  // val.config.ts
+  import { initVal } from "@valbuild/tanstack";
+  const { s, c, config, tanstackRouter } = initVal({ project: "org/project" });
+  ```
+
+  **Routes are first class.** A Val module for a route is named after the route
+  file it sits beside — `src/routes/posts.$postId.tsx` is served content by
+  `src/routes/posts.$postId.val.ts` — and its keys are the URLs that route serves:
+
+  ```ts
+  export default c.define(
+    "/src/routes/posts.$postId.val.ts",
+    s.router(tanstackRouter, s.object({ title: s.string() })),
+    { "/posts/hello-world": { title: "Hello world" } },
+  );
+  ```
+
+  `.` and `/` both separate segments, `$param` is a parameter, `$` is a splat, and
+  `index`, `route`, `(groups)` and `_pathless` layouts add no URL segment — the
+  same rules TanStack Router uses for the route file itself. Val validates every
+  key against that pattern, and Val Studio shows these modules as a sitemap under
+  **Pages**, where an editor can add a page.
+
+  Point the route generator away from your content files, in `vite.config.ts` and
+  `tsr.config.json`:
+
+  ```ts
+  tanstackStart({ router: { routeFileIgnorePattern: "\\.val\\.[tj]sx?$" } });
+  ```
+
+  See the [README](https://github.com/valbuild/val/blob/main/packages/tanstack/README.md)
+  for the full wiring, and `examples/tanstack` for a working app.
+
+  **Also fixed, for everyone:** `Internal.VERSION.core` was `null` in any ESM
+  bundle — it was read with `require("../package.json")` inside a `try`, so the
+  failure was silent. That version goes into every remote file ref and proxy mode
+  refuses to start without it. Every package now reads its version through a
+  static JSON import, which is inlined at build time.
+
+  Two smaller fixes that came out of running the whole toolchain against a
+  TanStack project:
+
+  - `val versions` reports `@valbuild/tanstack`, and `val debug` writes a snapshot
+    that names whichever framework package the captured project actually has.
+  - `@valbuild/eslint-plugin` reads a `tsconfig.json` that has comments in it. A
+    tsconfig is JSONC, and `JSON.parse` is not — so on any project whose tsconfig
+    carries a comment (the TanStack starter's does) the
+    `module-in-val-modules` rule threw `Expected double-quoted property name in
+JSON` on the first file and took the whole lint run with it.
+
+  Three fixes found by driving the Studio against a real TanStack app:
+
+  - **A draft image now loads on the page.** The source the Studio pushes to the
+    host page carries `patch_id` for any file whose bytes are still in a patch, so
+    the page asks `/api/val/files/...?patch_id=` rather than a `/public` path that
+    nothing has written yet. This was silent — the image just did not appear — and
+    it affects any page that reads media through the hooks rather than on the
+    server, `@valbuild/next` included.
+  - **A splat route no longer logs an error on every render.** TanStack returns
+    both `_splat` and `*` for the same parameter; Val reported the second as a
+    parameter it could not place in the path.
+  - The TanStack example and starter render a 404 page instead of throwing
+    `notFound()` from a component, which escaped to the error boundary and logged
+    `Error in renderToReadableStream` (and, with no not-found component
+    configured, aborted the response) on every miss.
+
+- Updated dependencies [[`c390397`](https://github.com/valbuild/val/commit/c390397cb5e203eb1bedae3a6fab15726e850b90)]:
+  - @valbuild/core@0.125.0
+  - @valbuild/shared@0.125.0
+  - @valbuild/server@0.125.0
+
 ## 0.124.0
 
 ### Patch Changes

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

@@ -1,7 +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 MediaCheckVerdict } from "./mediaChecks.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";
@@ -74,7 +74,7 @@ export declare function severityFor({ code, fixes, }: {
     code: ValDiagnosticCode;
     fixes?: ValidationFix[];
 }): DiagnosticSeverity;
-export declare function createValDiagnostics({ moduleFilePath, content, text, valRoot, snapshot, galleryChecks, mediaMetadataChecks, }: {
+export declare function createValDiagnostics({ moduleFilePath, content, text, valRoot, snapshot, galleryChecks, mediaChecks, }: {
     moduleFilePath: ModuleFilePath;
     content: ValModuleContent;
     /** Current text of the module, as the editor sees it. */
@@ -103,14 +103,14 @@ export declare function createValDiagnostics({ moduleFilePath, content, text, va
      */
     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.
+     * Verdicts for the media placeholders core emits unconditionally, from
+     * {@link resolveMediaChecks}. 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, and `image:check-remote` on
+     * every remote image, whether or not anything is wrong -- so publishing them
+     * raw puts a permanent warning on every image in the project.
      */
-    mediaMetadataChecks?: ReadonlyMap<string, MediaMetadataVerdict>;
+    mediaChecks?: ReadonlyMap<string, MediaCheckVerdict>;
 }): Diagnostic[];
 /**
  * Diagnostic for a project that could not be evaluated at all.

package/dist/declarations/src/{mediaMetadataChecks.d.ts → mediaChecks.d.ts}

@@ -1,17 +1,26 @@
 /**
- * Adjudicating the media metadata placeholders core emits unconditionally.
+ * Adjudicating the media 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`.
+ * A media schema cannot answer two of its own questions, because both need
+ * something core has no access to -- the bytes on disk, or the bytes on the
+ * content host. So it defers, by reporting an error that only means "nobody
+ * has looked yet":
  *
- * `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`).
+ *  - **Metadata.** 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`.
+ *  - **Remote refs.** Every `s.image().remote()` / `s.file().remote()` value
+ *    whose path is a remote ref gets `Remote image was not checked.` with
+ *    `image:check-remote` -- unconditionally, for every remote image in the
+ *    project.
+ *
+ * `val validate` resolves both by running the fix handler and then
+ * `createFixPatch` in report mode, which returns one error per real problem
+ * and nothing at all when there is none. The Studio cannot do that -- a
+ * browser has neither the filesystem nor the project's remote credentials --
+ * 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
@@ -20,8 +29,8 @@
  */
 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 = {
+/** One thing about a media value that a real check found to be wrong. */
+export type MediaCheckFinding = {
     message: string;
     /** The placeholder's own fixes, so the quick fix and severity survive. */
     fixes?: ValidationFix[];
@@ -29,12 +38,24 @@ export type MediaMetadataFinding = {
     value?: unknown;
 };
 /**
- * The verdict on one placeholder. Empty means the metadata agrees with the
- * file and nothing should be published.
+ * The verdict on one placeholder. Empty means the check passed -- the metadata
+ * agrees with the file, or the remote ref is sound -- and nothing should be
+ * published.
+ */
+export type MediaCheckVerdict = MediaCheckFinding[];
+/**
+ * Whether this error is the unconditional remote-ref deferral.
+ *
+ * Unlike the metadata deferral this needs no re-derivation: `image:check-remote`
+ * is attached to exactly one error in `ImageSchema.executeValidate`, the
+ * fall-through for a remote schema with a remote path, and `FileSchema` mirrors
+ * it. Everything else a remote media field can be wrong about carries a
+ * different fix (`image:upload-remote`, `image:download-remote`) or none.
  */
-export type MediaMetadataVerdict = MediaMetadataFinding[];
+export declare function isDeferredRemoteCheck(error: ValidationError): boolean;
 /**
- * Whether this error is the unconditional deferral rather than a real finding.
+ * Whether this error is the unconditional METADATA 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:
@@ -53,7 +74,7 @@ export type MediaMetadataVerdict = MediaMetadataFinding[];
  * 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
+ * `mediaChecks.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.
  *
@@ -72,34 +93,34 @@ export declare function isDeferredMediaMetadataCheck({ error, schema, }: {
     schema: unknown;
 }): boolean;
 /**
- * {@link isDeferredMediaMetadataCheck} for an error in a module, resolving the
- * schema it needs.
+ * Whether an error in a module is either deferral, resolving the schema the
+ * metadata classification 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, }: {
+export declare function isDeferredMediaCheckAt({ sourcePath, error, content, }: {
     sourcePath: string;
     error: ValidationError;
     content: ValModuleContent;
 }): boolean;
 /**
- * Adjudicate every deferred metadata placeholder in `validation`.
+ * Adjudicate every deferred media 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, }: {
+export declare function resolveMediaChecks({ validation, content, valRoot, remoteHost, }: {
     validation: Record<SourcePath, ValidationError[]>;
     content: ValModuleContent;
     valRoot: string;
     remoteHost?: string;
-}): Promise<Map<string, MediaMetadataVerdict>>;
+}): Promise<Map<string, MediaCheckVerdict>>;
 /**
  * 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;
+export declare function mediaCheckKey(sourcePath: string, error: ValidationError): string;

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

@@ -1,10 +1 @@
-/**
- * Version of this package, read from its own package.json.
- *
- * Mirrors how `@valbuild/core` reports `Internal.VERSION.core`
- * (see `packages/core/src/index.ts`): the built output lives one directory
- * below the package root, so `../package.json` resolves correctly. Returns
- * `null` rather than throwing if the file cannot be read — the version is only
- * ever used for display, never for behaviour.
- */
 export declare function getLanguageServerVersion(): string | null;