@valbuild/server 0.132.1 → 0.134.0

package/CHANGELOG.md

@@ -1,5 +1,140 @@
 # @valbuild/server
 
+## 0.134.0
+
+### Patch Changes
+
+- [#708](https://github.com/valbuild/val/pull/708) [`be78a9b`](https://github.com/valbuild/val/commit/be78a9b51678439f7ecb1c7f3887f9e8e1261a13) Thanks [@freekh](https://github.com/freekh)! - Fix `gitCommit` and `gitBranch` in `val.config.ts` never reaching the server,
+  and make them the one way to say it.
+
+  `val.config.ts` has had `gitCommit` and `gitBranch` for as long as it has had
+  anything, and a deployed app that set them resolved to no repository at all.
+  Nothing failed and nothing was logged: the commit was simply never sent, and
+  every patch the project saved recorded none.
+
+  ```ts
+  // val.config.ts — the normal Vercel shape, and it did nothing
+  initVal({
+    project: "org/project",
+    gitCommit: process.env.VERCEL_GIT_COMMIT_SHA,
+    gitBranch: process.env.VERCEL_GIT_COMMIT_REF,
+  });
+  ```
+
+  The two halves never met. The server wanted a nested
+  `git: { commit, branch }`, `val.config.ts` offered two flat keys, and nothing
+  mapped one onto the other — so the only thing that worked was
+  `VAL_GIT_COMMIT` / `VAL_GIT_BRANCH` in the environment.
+
+  Rather than teach the server to read both, the nested option is gone:
+  `ValApiOptions` and TanStack's `ValHttpMode` now take `gitCommit` and
+  `gitBranch`, the same two names `ValConfig` uses. There is one name for this
+  now, wherever it is set. The framework bindings already hand the server
+  `{ versions, ...config }`, so a project's config keys arrive with nothing to
+  map, and a host passing them directly is saying the same thing in the same
+  words.
+
+  Flat because of where these values come from. A platform supplies them as
+  `process.env.VERCEL_GIT_COMMIT_SHA` and friends, typed `string | undefined`,
+  and two optional strings take that as it comes — a nested object makes every
+  caller write the ternary that turns two maybe-strings into one maybe-object.
+
+  **Breaking for a host that passed `git` itself**, which is the nested option on
+  `ValApiOptions` and on TanStack's `http` mode. An app that only configures
+  `val.config.ts` or the environment is unaffected.
+
+  ```ts
+  // before
+  initValServer(valModules, config, {
+    http: { apiKey, valSecret, git: { commit, branch } },
+  });
+
+  // after
+  initValServer(valModules, config, {
+    http: { apiKey, valSecret, gitCommit: commit, gitBranch: branch },
+  });
+  ```
+
+  **What a commit is for**, and why its absence is worth a release rather than a
+  shrug: publishing turns pending patches into new `.val.ts` text, and to patch a
+  file you must first read it — at a commit. A project with none is a project
+  whose publishes read whatever the content service last had, rather than the
+  revision the deployed code was built from.
+
+  **One more behaviour change.** A commit and a branch have always been taken
+  together or not at all, and that check now sees config-supplied values too. A
+  project that sets exactly one of `gitCommit` and `gitBranch` used to have both
+  quietly ignored and will now be refused at startup, naming the missing half.
+  That is the configuration that would otherwise fail later, at a publish.
+
+- Updated dependencies [[`1c31dcc`](https://github.com/valbuild/val/commit/1c31dcca7f1bb0199350567fd579de29f48bb26d), [`688b9e3`](https://github.com/valbuild/val/commit/688b9e36b821323cda6870cdff03dd36ec3e782f), [`16c49ea`](https://github.com/valbuild/val/commit/16c49ea6dd97c7a96bbfdf211af9bab5884579e2), [`eaa265e`](https://github.com/valbuild/val/commit/eaa265e78d9f6d2a1b685c38901612b8a3704eed)]:
+  - @valbuild/ui@0.134.0
+  - @valbuild/core@0.134.0
+  - @valbuild/shared@0.134.0
+
+## 0.133.0
+
+### Minor Changes
+
+- [#700](https://github.com/valbuild/val/pull/700) [`802412b`](https://github.com/valbuild/val/commit/802412b92c06bc1abbca78c86885e39c8710dd83) Thanks [@freekh](https://github.com/freekh)! - http mode no longer needs a git repository
+
+  A Val app can now run in http mode with no commit and no branch — its content
+  service is the store of record, and git is an optional mirror of the code. This
+  is what `fs` mode has always done: it has never had git, and it works.
+
+  Before this, `VAL_API_KEY` and `VAL_SECRET` were not enough. `VAL_GIT_COMMIT`
+  and `VAL_GIT_BRANCH` were required too, so a deployment with no commit to name
+  either threw at boot or fell through to `fs` mode and reached for a working
+  tree that was not there.
+
+  **Breaking, if you pass `http` options in code.** `gitCommit` and `gitBranch`
+  are replaced by one optional `git`:
+
+  ```diff
+   initValServer(valModules, config, {
+     http: {
+       apiKey,
+       valSecret,
+  -    gitCommit: process.env.VAL_GIT_COMMIT,
+  -    gitBranch: "main",
+  +    // Only for a project whose content is mirrored into a repository.
+  +    // Omit it entirely otherwise.
+  +    git: { commit: process.env.VAL_GIT_COMMIT, branch: "main" },
+     },
+   })
+  ```
+
+  `VAL_GIT_COMMIT` and `VAL_GIT_BRANCH` still work and are still read; they are
+  simply no longer required. Set both or neither — a commit without a branch, or
+  a branch without a commit, is refused at startup with a message naming the
+  missing half, rather than failing later at a publish.
+
+  **What a commit is for, where you have one.** Turning pending patches into new
+  `.val.ts` text means reading the current text first, and that read goes to the
+  content service at that commit. It is the publish path, not the serving path: a
+  committed render reads the source compiled into the build and asks the content
+  service nothing. With no repository there is nothing to write `.val.ts` into,
+  so a publish records the module's data and its schema and skips the file — and
+  that data is what history reads, so nothing is lost.
+
+  **A publish can now be refused by name, before it is attempted.** If a project
+  mirrors its commits into a repository but the running deployment was built
+  before that repository existed, it has no commit to write the mirror against.
+  Publishing anyway would save the content and silently leave the repository
+  behind. The Studio now disables Publish and shows why, and `/save` refuses with
+  a `no-base` code instead of failing partway.
+
+  **Also:** `ValCommit` and `HistoricalCommit` have nullable `parentCommitSha`
+  and `clientCommitSha`, and `/stat`'s `commitSha` is optional. A root commit has
+  no parent, and a publisher with no repository does not report where it was. If
+  you read these fields, handle `null`.
+
+### Patch Changes
+
+- Updated dependencies [[`2b9a51b`](https://github.com/valbuild/val/commit/2b9a51b7dbe2dff53b7686a4f3b7eb9bc5784fae), [`802412b`](https://github.com/valbuild/val/commit/802412b92c06bc1abbca78c86885e39c8710dd83)]:
+  - @valbuild/ui@0.133.0
+  - @valbuild/shared@0.133.0
+
 ## 0.132.1
 
 ### Patch Changes

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

@@ -137,7 +137,8 @@ export declare abstract class ValOps {
         nonce: string;
         baseSha: BaseSha;
         schemaSha: SchemaSha;
-        commitSha: CommitSha;
+        /** Absent for a project with no repository. See `git` on ValApiOptions. */
+        commitSha?: CommitSha;
         sourcesSha: SourcesSha;
         patches: PatchId[];
     } | {
@@ -401,6 +402,42 @@ export declare abstract class ValOps {
     } | {
         errorType: "patch-head-conflict";
     }>>;
+    /**
+     * Why a publish cannot happen here, or `null` when one can.
+     *
+     * Named rather than thrown, and asked BEFORE the click: the Studio shows the
+     * reason and disables the action, instead of letting someone write a commit
+     * message and then meeting a failure from four layers down.
+     *
+     * `no-base` is the only code so far and means what it says: there is nowhere
+     * for this publish's commit to be based. Note which way round that is --
+     * a project whose content service is the store of record always HAS a base
+     * (the service's own chain, which mints its own shas), so the refusal is not
+     * about missing git. It is about a deployment that cannot do what its
+     * project requires.
+     */
+    publishRefusal(): PublishRefusal | null;
+    /**
+     * Whether a commit here produces `.val.ts` TEXT as well as data.
+     *
+     * True everywhere there is somewhere to put it: a working tree in `fs` mode,
+     * a host holding its own source in memory mode, a git repository in `http`
+     * mode. False for an `http` project whose content service is the store of
+     * record and which has no repository attached -- see `git` on
+     * {@link ValApiOptions}.
+     *
+     * WHAT IS NOT AFFECTED, and it is the part worth being sure of:
+     * `moduleVersions` -- what each changed module IS after the commit, with its
+     * schema -- comes from `getSources(analysis)`, which applies the ops to
+     * Source in the stores. It does not go near the file text. So a commit with
+     * no mirror still records everything history and a later `connect-github`
+     * fold need; what it does not record is a rendering of that data as code.
+     *
+     * WHAT IS: the ops are no longer applied to the file text as well, so a
+     * patch that would not fit the `.val.ts` is not reported here. That check
+     * only ever existed for the text being produced, and there is none.
+     */
+    protected readonly mirrorsSourceFiles: boolean;
     /**
      * Take the `.val.ts` text a commit produced as the new committed source.
      *
@@ -624,6 +661,18 @@ export type OpsMetadata<T extends "file" | "image"> = {
     }))[];
 };
 export type BinaryFileType = "file" | "image";
+/**
+ * Why a publish is refused, in a form a person can be shown.
+ *
+ * `code` is for the Studio to branch on and `message` is what it says. Both,
+ * rather than a code and a lookup table on the client: the server knows what
+ * is actually missing -- which branch, which commit -- and a client-side table
+ * could only ever say the generic version.
+ */
+export type PublishRefusal = {
+    code: "no-base";
+    message: string;
+};
 export type PreparedCommit = {
     /**
      * Updated / new source files that are ready to be committed / saved.

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

@@ -1,6 +1,6 @@
 import { type PatchId, type ModuleFilePath, ValModules } from "@valbuild/core";
 import type { Patch as PatchT, ParentRef as ParentRefT } from "@valbuild/core/patch";
-import { type AuthorId, type BaseSha, BinaryFileType, type CommitSha, GenericErrorMessage, MetadataOfType, OpsMetadata, PreparedCommit, ValOps, ValOpsOptions, WithGenericError, SaveSourceFilePatchResult, type PatchGroupMembership, SchemaSha, OrderedPatchesMetadata, OrderedPatches, SourcesSha } from "./ValOps.js";
+import { type AuthorId, type BaseSha, BinaryFileType, type CommitSha, GenericErrorMessage, MetadataOfType, OpsMetadata, PreparedCommit, ValOps, ValOpsOptions, WithGenericError, SaveSourceFilePatchResult, type PatchGroupMembership, SchemaSha, OrderedPatchesMetadata, OrderedPatches, SourcesSha, type PublishRefusal } from "./ValOps.js";
 import { z } from "zod";
 import type { HistoryError } from "./history/HistoryError.js";
 import type { AffectedFile, StoredModuleVersion, CommitPage, CommitPatch, HistoricalCommit } from "./history/types.js";
@@ -23,16 +23,69 @@ export type PatchGroupMutationResult = {
 export declare class ValOpsHttp extends ValOps {
     private readonly contentUrl;
     private readonly project;
-    private readonly commitSha;
-    private readonly branch;
+    /**
+     * The repository this project's commits are mirrored into, or `null`.
+     *
+     * `null` is a project whose content service is the store of record: it
+     * mints its own commit shas, and it knows this project's branch from the
+     * project itself. Every request below that would have carried a branch and
+     * a commit omits them instead, and the service answers from the project's
+     * own chain -- which is where those answers always came from.
+     *
+     * It is NOT a degraded mode. The one thing that genuinely needs a
+     * repository is producing the `.val.ts` text a commit mirrors, and a
+     * project with no repository has nothing to mirror into. See `git` on
+     * {@link ValApiOptions}.
+     */
+    private readonly git;
     private readonly authHeaders;
     private readonly root;
     /** Val's content service owns the store. See {@link ValOps.patchesAreLocal}. */
     readonly patchesAreLocal = false;
     /** See {@link ValOps.requiresAuth}. */
     readonly requiresAuth = true;
-    constructor(contentUrl: string, project: string, commitSha: string, // TODO: CommitSha
-    branch: string, 
+    /**
+     * A commit mirrors into `.val.ts` only when there is a repository.
+     *
+     * See {@link ValOps.mirrorsSourceFiles}. Set in the constructor rather than
+     * as an initialiser because it depends on `git`, and a class field
+     * initialiser runs before the constructor body has assigned it.
+     */
+    protected readonly mirrorsSourceFiles: boolean;
+    /**
+     * What the content service last said this project expects of its publisher.
+     *
+     * `null` until something has asked it, which in practice is the first poll.
+     * It is remembered rather than asked for on demand because the answer is
+     * only wanted on the publish path, and that path already fetches the
+     * patches it is publishing -- so a dedicated request would be a second round
+     * trip for two fields that just arrived.
+     *
+     * It can be one poll out of date, and that is the right amount: the thing it
+     * changes is whether this deployment can mirror commits into a repository,
+     * which changes when a project CONNECTS one -- and a project that has just
+     * connected is one whose builds are about to be replaced anyway.
+     */
+    private projectExpectation;
+    constructor(contentUrl: string, project: string, 
+    /**
+     * The repository this project's commits are mirrored into, or `null`.
+     *
+     * `null` is a project whose content service is the store of record: it
+     * mints its own commit shas, and it knows this project's branch from the
+     * project itself. Every request below that would have carried a branch and
+     * a commit omits them instead, and the service answers from the project's
+     * own chain -- which is where those answers always came from.
+     *
+     * It is NOT a degraded mode. The one thing that genuinely needs a
+     * repository is producing the `.val.ts` text a commit mirrors, and a
+     * project with no repository has nothing to mirror into. See `git` on
+     * {@link ValApiOptions}.
+     */
+    git: {
+        commit: string;
+        branch: string;
+    } | null, 
     /**
      * An api key (how the app itself authenticates) or a personal access token
      * (how the CLI authenticates after `val login`). Same two shapes as
@@ -50,6 +103,29 @@ export declare class ValOpsHttp extends ValOps {
          */
         root?: string;
     });
+    /**
+     * A deployment that cannot mirror a project which expects to be mirrored.
+     *
+     * This is the one shape of "no base" that exists, and it is not the one it
+     * sounds like. A project with no repository is fine: the content service is
+     * the store of record for it and mints its own commit shas, so there is
+     * always somewhere for the commit to go. What is refused is the mismatch --
+     * a project whose commits are mirrored into a repository, being published by
+     * a build that was made before it had one and so has no commit to produce
+     * that mirror against.
+     *
+     * It is a REAL state rather than a defensive check: it is exactly what a
+     * deployment looks like between a project connecting a repository and its
+     * next build going out. Left unchecked, such a publish writes the data and
+     * silently fails to mirror it, and the repository quietly falls behind the
+     * content nobody is told about.
+     *
+     * `null` when the service did not say (see `project` on the response
+     * schema): an older content service is not evidence of anything, and
+     * refusing every publish against one would be a worse failure than not
+     * checking.
+     */
+    publishRefusal(): PublishRefusal | null;
     onInit(): Promise<void>;
     getPresignedAuthNonce(profileId: string, corsOrigin: string): Promise<{
         status: "success";
@@ -80,7 +156,8 @@ export declare class ValOpsHttp extends ValOps {
         baseSha: BaseSha;
         schemaSha: SchemaSha;
         sourcesSha: SourcesSha;
-        commitSha: CommitSha;
+        /** Absent for a project with no repository. See `git` on ValApiOptions. */
+        commitSha?: CommitSha;
         commits: ValCommit[];
         deployments: ValDeployment[];
         patches: PatchId[];

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

@@ -84,21 +84,50 @@ type ValServerOverrides = Partial<{
      */
     patchStore: ValPatchStore;
     /**
-     * Current git commit.
-     *
-     * Required if mode is "proxy".
+     * The git commit this code was built from, and the branch a publish mirrors
+     * into -- for a project that HAS a repository.
+     *
+     * OPTIONAL, including in http mode, and absent is the normal case for a
+     * project whose content service is the store of record. It used to be
+     * required, which made a repository a precondition for editing anything: a
+     * deployment with no commit to name fell through to `fs` mode and reached
+     * for a working tree that was not there.
+     *
+     * What it is FOR, where there is one: a publish turns pending patches into
+     * new `.val.ts` text, and to patch a file you must first read it. That read
+     * goes to the content service AT THIS COMMIT. Give it a commit the deployed
+     * code did not come from and the publish writes over a different version of
+     * the file than the one the site is running.
+     *
+     * It is NOT what a committed render reads -- that reads the source compiled
+     * into the build and asks the content service nothing.
+     *
+     * A normal deploy bakes this at build time, because the commit really is a
+     * property of those bytes. `VAL_GIT_COMMIT` / `VAL_GIT_BRANCH` supply it
+     * where a build system sets environment variables instead.
+     *
+     * FLAT, and the same two names `val.config.ts` uses, so that there is one
+     * way to say this rather than two. An app reads these off its platform --
+     * `process.env.VERCEL_GIT_COMMIT_SHA` and friends, which are typed
+     * `string | undefined` -- and a pair of optional strings takes that as it
+     * comes. A nested `{ commit, branch }` would make every caller write the
+     * ternary that turns two maybe-strings into one maybe-object. Sharing the
+     * names with `ValConfig` is what makes the bindings' `{ versions,
+     * ...config }` carry them here with nothing to map.
+     *
+     * Taken together or not at all: `initHandlerOptions` refuses one without
+     * the other rather than resolving half a repository.
      *
      * @example "e83c5163316f89bfbde7d9ab23ca2e25604af290"
      */
-    gitCommit: string;
+    gitCommit?: string;
     /**
-     * Current git branch.
-     *
-     * Required if mode is "proxy".
+     * The branch a publish mirrors into. See {@link ValApiOptions.gitCommit},
+     * which this is required with and meaningless without.
      *
      * @example "main"
      */
-    gitBranch: string;
+    gitBranch?: string;
     /**
      * The base url of Val.
      *

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

@@ -121,8 +121,17 @@ export type ValServerConfig = ValServerOptions & ({
     mode: "http";
     apiKey: string;
     project: string;
-    commit: string;
-    branch: string;
+    /**
+     * The repository this project's commits are mirrored into, if any.
+     *
+     * Absent is a project whose content service is the store of record --
+     * which is every project that has not attached a repository, and the
+     * normal case. See `git` on {@link ValApiOptions}.
+     */
+    git?: {
+        commit: string;
+        branch: string;
+    };
     root?: string;
     config: ValConfig;
 }

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

@@ -205,6 +205,14 @@ export declare function handleJsonValuesExtractEntry(ctx: FixHandlerContext): Pr
  * `fixableErrorMessage` rather than a plain error, because the error IS fixable
  * — just not by this command.
  */
+/**
+ * A view pointer that names a module its schema does not.
+ *
+ * Nothing to look up and nothing to ask: the schema names the module, so the
+ * one correct value is already known. `createFixPatch` writes it — this handler
+ * exists to send it there, and to say what `--fix` would do when it is off.
+ */
+export declare function handleViewCheckModule(ctx: FixHandlerContext): Promise<FixHandlerResult>;
 export declare function handleExternalUpload(): Promise<FixHandlerResult>;
 export declare const currentFixHandlers: Record<Exclude<ValidationFix, "keyof:check-keys" | "router:check-route" | "locale:check-locale" | "record:fill-keys">, FixHandler>;
 export declare const fixHandlers: Record<string, FixHandler>;

package/dist/declarations/src/history/types.d.ts

@@ -4,8 +4,10 @@ import type { HistoryError } from "./HistoryError.js";
 /** One commit, as history lists it. */
 export type HistoricalCommit = {
     commitSha: string;
-    parentCommitSha: string;
-    clientCommitSha: string;
+    /** `null` for a root commit. See `ValCommit`. */
+    parentCommitSha: string | null;
+    /** `null` when the publisher did not say where it was. See `ValCommit`. */
+    clientCommitSha: string | null;
     branch: string;
     createdBranch: string | null;
     creator: string | null;