@valbuild/server 0.132.0 → 0.133.0

package/CHANGELOG.md

@@ -1,5 +1,127 @@
 # @valbuild/server
 
+## 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
+
+- [#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

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[];
@@ -282,6 +359,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/ValRouter.d.ts

@@ -84,21 +84,34 @@ type ValServerOverrides = Partial<{
      */
     patchStore: ValPatchStore;
     /**
-     * Current git commit.
+     * The git commit this code was built from, and the branch a publish mirrors
+     * into -- for a project that HAS a repository.
      *
-     * Required if mode is "proxy".
+     * 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.
      *
-     * @example "e83c5163316f89bfbde7d9ab23ca2e25604af290"
-     */
-    gitCommit: string;
-    /**
-     * Current git branch.
+     * 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.
      *
-     * Required if mode is "proxy".
+     * It is NOT what a committed render reads -- that reads the source compiled
+     * into the build and asks the content service nothing.
      *
-     * @example "main"
+     * 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.
+     *
+     * @example { commit: "e83c5163316f89bfbde7d9ab23ca2e25604af290", branch: "main" }
      */
-    gitBranch: string;
+    git?: {
+        commit: string;
+        branch: string;
+    };
     /**
      * The base url of Val.
      *

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;
 } | {
@@ -90,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/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;

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.