@valbuild/server 0.131.0 → 0.132.1

package/CHANGELOG.md

@@ -1,5 +1,90 @@
 # @valbuild/server
 
+## 0.132.1
+
+### Patch Changes
+
+- [#695](https://github.com/valbuild/val/pull/695) [`c07b1ab`](https://github.com/valbuild/val/commit/c07b1abe30e226c80ef7ec4b4f0f5ccdae061c11) Thanks [@freekh](https://github.com/freekh)! - A publish result can now say which commit it was built on, and what tree it points at
+
+  `CommitResult` gains two optional fields, `parent` and `tree`, filled in from
+  the content service's commit response when it reports them.
+
+  Both matter to a host that keeps its own record of what each commit changed —
+  a build cache, or an incremental publisher that rebuilds from the last thing it
+  built rather than from scratch. Such a host can only tell whether its record is
+  COMPLETE by chaining the commits it holds back to the one it last built. With
+  just a sha per commit the record is a set of snapshots with no way to notice a
+  gap, so a commit somebody else made in between is silently absent instead of
+  detected — and the host rebuilds from a source tree that is missing a change it
+  never knew about. `parent` is what closes that.
+
+  `tree` identifies the CONTENT of a commit rather than the commit itself, so two
+  commits carrying the same tree are the same source. A host that has already
+  built one of them can recognise the other and skip the work.
+
+  Both are optional, and absent means NOT REPORTED rather than absent-in-git: a
+  content service that predates these fields sends neither, and a caller must not
+  read a missing `parent` as "this is a root commit". They are plain strings
+  rather than branded shas for the same reason — they are passed through as what
+  a separately versioned service said, not as something this end has checked.
+
+  Nothing changes for a host that does not look at them. The publish route's own
+  response is unchanged.
+
+- [#678](https://github.com/valbuild/val/pull/678) [`cbfa2b8`](https://github.com/valbuild/val/commit/cbfa2b884898f1603bde8e5aa5cd9da78778101f) Thanks [@freekh](https://github.com/freekh)! - Putting a whole module back works for `.jsonValues()` records
+
+  A `.jsonValues()` record's entries are not in the module's source: the `.val.ts`
+  holds `c.json(() => import("./entry.val.json"))` per entry and the content lives
+  in those files. Val already routed a patch that named an entry key into the
+  right file, but a patch that replaced the **whole record** named no key — so it
+  was applied as an ordinary source edit, writing over the imports that make the
+  entries load at all. "Put everything back" in the history pane left such a module
+  out for exactly that reason.
+
+  A whole-record write is now expanded into per-entry ops before anything acts on
+  it: an entry added, one removed, one changed, and nothing at all for an entry
+  that already holds what the write says — so putting a module back does not
+  rewrite every file in it. The same expansion produces the draft the Studio shows
+  and the files a publish writes, so a draft cannot show one thing and publish
+  another.
+
+  Nothing that writes a patch has to know a record is `.jsonValues()`: write the
+  module as if it were ordinary content, and it lands in the right files.
+
+  "Put everything back" and "Restore this whole module" now cover `.jsonValues()`
+  modules. They read each entry as it was at the commit and put the content back —
+  never the recorded source, which is markers rather than content, and is now
+  refused rather than written.
+
+- Updated dependencies [[`c9a5cd3`](https://github.com/valbuild/val/commit/c9a5cd3a4ab5908ecb9757b7a95db17a77e3b173), [`f413c5c`](https://github.com/valbuild/val/commit/f413c5cebca27ba82052825abc8c632b6177747e), [`1ddf245`](https://github.com/valbuild/val/commit/1ddf245ec73ad5af8099c3d18d4d33c6a1cc1254), [`a19997a`](https://github.com/valbuild/val/commit/a19997a542e65cc1375837b1bdb11c8af9e10160), [`76c5d41`](https://github.com/valbuild/val/commit/76c5d41c3afa7cc8180d156c9e19fb082af7fba4), [`cbfa2b8`](https://github.com/valbuild/val/commit/cbfa2b884898f1603bde8e5aa5cd9da78778101f), [`003419a`](https://github.com/valbuild/val/commit/003419ab72f3069d92e67dfea931d5accc63e730)]:
+  - @valbuild/ui@0.132.1
+
+## 0.132.0
+
+### Minor Changes
+
+- [#689](https://github.com/valbuild/val/pull/689) [`72cc676`](https://github.com/valbuild/val/commit/72cc6765e92a6e72b5c09ddd9eed8efa7ce899f2) Thanks [@freekh](https://github.com/freekh)! - `VAL_ENV=app` selects `http` mode.
+
+  A host knows WHERE it is running; which Val mode that implies is Val's to
+  derive. `VAL_ENV=app` says "this is the Val app" — a project built in a browser
+  and served from a Worker isolate — and Val reads that as http mode: there is no
+  disk, so `fs` is never the right fall-through, and the content is Val's own,
+  read over HTTP at a commit like any other deployed app.
+
+  Unlike `VAL_MODE=memory`, this **selects** the mode rather than only refusing a
+  fall-through, because everything http mode needs is an environment variable. The
+  point is what happens when one is missing: inference reads an absent
+  `VAL_API_KEY` as "not a proxy" and resolves `fs` mode, which in an isolate fails
+  on `.val/patches.lock` — a path, two layers below the actual mistake. Now each
+  of `VAL_API_KEY`, `VAL_SECRET`, `VAL_PROJECT`, `VAL_GIT_COMMIT` and
+  `VAL_GIT_BRANCH` is named when it is the one that is not set, and the message
+  says which variable put the app in http mode.
+
+  An explicit `VAL_MODE` still wins, including when it is a typo that has to be
+  refused, and `http` is still not a value `VAL_MODE` accepts. A host that passes
+  `sourceFiles` still gets memory mode: that is checked before the environment is
+  consulted at all, so a build published by an older platform keeps working.
+
 ## 0.131.0
 
 ### Minor Changes

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

@@ -282,6 +282,10 @@ export declare class ValOpsHttp extends ValOps {
         isNotFastForward?: boolean;
         updatedFiles: string[];
         commit: CommitSha;
+        /** See `CommitResult.parent`: absent means not reported. */
+        parent?: string;
+        /** See `CommitResult.tree`: absent means not reported. */
+        tree?: string;
         branch: string;
         error?: undefined;
     } | {

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

@@ -76,6 +76,37 @@ export type CommitResult = {
     isNotFastForward?: boolean;
     updatedFiles: string[];
     commit: CommitSha;
+    /**
+     * The commit this one was built on.
+     *
+     * Optional because it is only as available as the content service is
+     * willing to say: a service that predates this field sends nothing, and
+     * `undefined` there means "not reported", never "this commit has no
+     * parent". A host that needs it has to handle its absence rather than
+     * treat it as a root commit.
+     *
+     * What it is FOR: a host that keeps its own record of what each commit
+     * changed -- a build cache, an incremental publisher -- can only tell
+     * whether its record is complete by chaining the commits it holds back to
+     * the one it last built. Without a parent the record is a set of
+     * snapshots with no way to notice a gap, and a commit made by somebody
+     * else in between is silently absent rather than detected.
+     *
+     * Not `CommitSha`-typed for the same reason it is optional: it is
+     * reported by a remote service and validated on arrival, and a branded
+     * type here would suggest this end had checked it.
+     */
+    parent?: string;
+    /**
+     * The git tree this commit points at.
+     *
+     * Optional for the same reason as {@link parent}. A tree hash identifies
+     * the CONTENT of a commit rather than the commit itself, so two commits
+     * with the same tree are the same source -- which is what lets a host
+     * recognise that a commit it is being asked to build is one it has built
+     * already, under a different sha, and skip the work.
+     */
+    tree?: string;
     branch: string;
     error?: undefined;
 } | {

package/dist/declarations/src/patch/jsonValuesPatch.d.ts

@@ -1,4 +1,4 @@
-import type { PatchId, SerializedSchema } from "@valbuild/core";
+import { type PatchId, type SerializedSchema } from "@valbuild/core";
 import type { PatchSourceError } from "../ValOps.js";
 import { result } from "@valbuild/core/fp";
 import { JSONValue, Operation, Patch, PatchError } from "@valbuild/core/patch";
@@ -30,6 +30,74 @@ export type JsonValuesOpClass = {
  * `.jsonValues()` record.
  */
 export declare function classifyJsonValuesOp(schema: SerializedSchema, opPath: string[]): JsonValuesOpClass;
+/**
+ * Is this op a write of the WHOLE record at the root of a `.jsonValues()`
+ * module?
+ *
+ * The one op {@link classifyJsonValuesOp} cannot classify: it finds the entry
+ * key by walking the op path, and the root path has no segments to walk, so a
+ * root write reads as `normal` and gets applied to the `.val.ts` - writing
+ * markers over the `c.json(() => import(...))` calls that make the entries load
+ * at all. {@link expandJsonValuesRootOp} turns it into ops that DO name a key,
+ * which everything downstream already handles.
+ *
+ * `add` counts as well as `replace`: at the root both mean "the document is now
+ * this" (see `JSONOps`), so both have to be expanded or the unexpanded one is
+ * the same bug again.
+ *
+ * The value has to BE a record, and that is part of the question rather than a
+ * check inside the expansion: a `.jsonValues()` record can be nullable, and
+ * `null` at the root means the module no longer has a record at all - there are
+ * no entries to write, and it is an ordinary `.val.ts` write, exactly as it was
+ * before any of this existed. Same for any other non-record value: not a
+ * whole-record write, so not this conversion's to route.
+ */
+export declare function isJsonValuesRootOp(schema: SerializedSchema, op: Operation): boolean;
+/**
+ * One entry as it stands right now, for {@link expandJsonValuesRootOp} to
+ * expand against.
+ *
+ * The key set decides add-vs-replace-vs-remove. The content, where the caller
+ * has it, decides whether an op is emitted at all: an entry whose content is
+ * already what the root write says is left alone rather than rewritten, so
+ * putting a module back does not touch every `*.val.json` it did not change.
+ * `undefined` means "this entry exists, content unknown" - which is what the
+ * Studio's draft source has, because the source holds markers - and yields a
+ * `replace`, the safe answer.
+ */
+export type CurrentJsonEntries = ReadonlyMap<string, JSONValue | undefined>;
+/**
+ * Fans a whole-record write at a `.jsonValues()` module's root out into ops
+ * that each name an entry key.
+ *
+ * This is THE conversion, and it has exactly one implementation on purpose: the
+ * commit flow (`ValOps.prepare`) and the read side that builds draft content
+ * ({@link applyJsonValuesEntryPatches}) both expand through here, so a draft
+ * cannot show something other than what publishing writes. A second
+ * implementation of the same rule would differ silently, which is the whole
+ * failure mode this exists to prevent.
+ *
+ * The value must be the entries' CONTENT. A module's Source is markers, not
+ * content, so a Source handed over here is refused rather than written: that is
+ * the shape of the original bug (a revert replaying the archived Source), and
+ * it is not recoverable afterwards - the markers replace the entries' content
+ * on disk.
+ */
+export declare function expandJsonValuesRootOp(op: Operation, currentEntries: CurrentJsonEntries): result.Result<Operation[], PatchError>;
+/**
+ * What a whole-record write says about ONE entry: the same rule
+ * {@link expandJsonValuesRootOp} applies to all of them.
+ *
+ * For a reader that is about one entry. Expanding the whole record to find the
+ * one op that names its key costs an op per entry per entry read - the record
+ * squared, on exactly the large records this feature is for. The rule itself is
+ * `writeForEntry`, shared with the expansion above, so the two cannot come to
+ * disagree; only the loop around it differs.
+ *
+ * `null` means the write says nothing about this entry: it holds that content
+ * already, or the record does not name it and it does not exist.
+ */
+export declare function expandJsonValuesRootOpForKey(op: Operation, entryKey: string, currentEntries: CurrentJsonEntries): result.Result<Operation | null, PatchError>;
 /**
  * Finds every `.jsonValues()` record in a module's schema that is NOT the
  * module's root, returning the path to each within the module source.