@valbuild/server 0.141.0 → 0.142.0

package/CHANGELOG.md

@@ -1,5 +1,38 @@
 # @valbuild/server
 
+## 0.142.0
+
+### Patch Changes
+
+- [#805](https://github.com/valbuild/val/pull/805) [`1ec4ff4`](https://github.com/valbuild/val/commit/1ec4ff4165a33f2248b52608ff58e626523e4212) Thanks [@freekh](https://github.com/freekh)! - Fix: a draft preview could miss a change its editor had just saved. Draft pages scoped to your own changes worked out which pending changes are yours from a list of patch groups remembered for a second, so a save followed by a reload inside that second rendered without the save. The draft page now takes your changes from the same answer as the changes themselves, and any save, discard, stage or unstage through the server forgets the remembered list.
+
+- [#805](https://github.com/valbuild/val/pull/805) [`bb63738`](https://github.com/valbuild/val/commit/bb63738aabed1cf1287611ecaab7c35fc4b08a12) Thanks [@freekh](https://github.com/freekh)! - Publish in a proposal: merging it into the site. The dialog shows whether it can go now, and names who to ask when it cannot; Publish saves anything unsaved, builds the site with the proposal in this tab, and content checks it renders and makes it live as one change. A merged proposal is finished: its Studio says so above the editor, and anything written in it while it merged is moved to a new proposal, which the Studio offers to open. Review in a proposal now compares it with the site, saved and unsaved changes alike.
+
+- [#805](https://github.com/valbuild/val/pull/805) [`fa03698`](https://github.com/valbuild/val/commit/fa03698ef0f2c7a6df334b4ba0e41843bde60029) Thanks [@freekh](https://github.com/freekh)! - Groundwork for proposals on the Val platform: a server can be told it is running at a proposal's address (`proposal` in the http options, `proposalFromEnv` to read it from the platform). There, the content the proposal has saved replaces the bundled content for those modules on every read, edits go to the proposal's branch, and Save commits to the proposal instead of the site. Nothing changes for a site that is not given a proposal.
+
+- [#805](https://github.com/valbuild/val/pull/805) [`3d2b9e8`](https://github.com/valbuild/val/commit/3d2b9e8c11aa6a4449527e2a1bbb363566797a14) Thanks [@freekh](https://github.com/freekh)! - Proposals in the Studio, for projects on the Val platform that have them turned on: a switcher in the top bar to move between the site and its proposals, New proposal, Rename, Close and All proposals (with Reopen), and — inside a proposal — Save where Publish is, in the proposal's colour. Nothing is shown for a project without proposals. At a proposal's address the server now refuses to publish to the site, so a Save there can never start a site build.
+
+- [#815](https://github.com/valbuild/val/pull/815) [`a3236a5`](https://github.com/valbuild/val/commit/a3236a5f2c41b92422b40340dba060b53218c6ab) Thanks [@freekh](https://github.com/freekh)! - Fixed: a project that is not connected to Val Build yet (no `project` in `val.config`) no longer gets errors from the Studio on every page load. The Studio used to ask for the assistant, its conversations and the project's members anyway, and got `401` and `500` answers that showed up in the browser console and as an issue badge in the Next.js dev overlay. It now asks only once there is a project to ask about, and the assistant is hidden until there is. The chat used to say "Login to use AI chat" in that state, which no login could fix.
+
+  A project named only in the `VAL_PROJECT` environment variable counts as connected, as it always did on the server.
+
+- Updated dependencies [[`1671bce`](https://github.com/valbuild/val/commit/1671bce6f0b65dac77e51655f24ef825f4671ebb), [`bb63738`](https://github.com/valbuild/val/commit/bb63738aabed1cf1287611ecaab7c35fc4b08a12), [`3d2b9e8`](https://github.com/valbuild/val/commit/3d2b9e8c11aa6a4449527e2a1bbb363566797a14), [`a3236a5`](https://github.com/valbuild/val/commit/a3236a5f2c41b92422b40340dba060b53218c6ab), [`f14e0aa`](https://github.com/valbuild/val/commit/f14e0aabedba07b832b1453d49635af5d2fbc019), [`521fe94`](https://github.com/valbuild/val/commit/521fe9400c0b660aa5b3642942cd0cc26622f193)]:
+  - @valbuild/ui@0.142.0
+  - @valbuild/shared@0.142.0
+
+## 0.141.1
+
+### Patch Changes
+
+- [#808](https://github.com/valbuild/val/pull/808) [`14b18d7`](https://github.com/valbuild/val/commit/14b18d7cb145cec1bc1cd832b9ca857ff4b45adc) Thanks [@freekh](https://github.com/freekh)! - A project with `files: { remote: true }` can save text edits without remote-file credentials: in local development without `val login` or a project id, and on a server without `VAL_API_KEY`.
+
+  Before, a save asked for remote credentials whenever any schema in the project was remote. With `files: { remote: true }` that is every media schema, so every save was refused, even a typo fix. Now it asks only when the change being saved contains a remote file.
+
+  When uploads are unavailable, the Studio now shows a card above the editor. It says what is wrong and gives the fix: a link to admin.val.build or the `val login` command to copy. When the cause is missing setup (no project id, not logged in, no API key) it also says that text edits still save and publish. Dismissing it leaves an "Uploads off" item in the status bar, or in the account sheet on a phone, that brings it back. This replaces the red bar that covered the top of the Studio, the Publish button included, and the login dialog that opened on every load.
+
+- Updated dependencies [[`6faacda`](https://github.com/valbuild/val/commit/6faacda398fc92bec187b7afe07a53228a6f2a3b), [`14b18d7`](https://github.com/valbuild/val/commit/14b18d7cb145cec1bc1cd832b9ca857ff4b45adc)]:
+  - @valbuild/ui@0.141.1
+
 ## 0.141.0
 
 ### Minor Changes

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

@@ -43,6 +43,14 @@ export type ValOpsOptions = {
     disableFilePolling?: boolean;
     disableFileWatcher?: boolean;
     config: ValConfig;
+    /**
+     * Source that replaces what the modules evaluate to, for the modules it
+     * names: a proposal's saves (`ValProposal` in `./proposal`), the third
+     * source provider beside committed and draft. Applied once, as the modules
+     * are first read, so every read after it -- the tree, validation, previews,
+     * the next save's prepare -- starts from it, and the SHAs describe it.
+     */
+    snapshotSources?: Sources;
 };
 export declare abstract class ValOps {
     private readonly valModules;
@@ -76,6 +84,12 @@ export declare abstract class ValOps {
      * hash. Re-folding with the wrong list changes the base SHA for no reason.
      */
     private shaModuleErrors;
+    /**
+     * The SITE's Source for the modules a proposal's snapshot replaced: what the
+     * bundle evaluated to before the snapshot went over it. Kept for
+     * {@link siteSourcesUnderSnapshot}, and only where there is a snapshot.
+     */
+    private siteSourcesBeforeSnapshot;
     /**
      * What a save has told us each `.jsonValues()` entry now holds.
      *
@@ -156,6 +170,13 @@ export declare abstract class ValOps {
         networkError?: boolean;
     }>;
     private initSources;
+    /**
+     * In a proposal: the SITE's Source for every module the proposal has saved,
+     * as the build it is based on evaluated it -- what the proposal is compared
+     * against, and what merging it changes. Every other module is the same in
+     * both, so it is not sent. `null` anywhere that is not a proposal.
+     */
+    siteSourcesUnderSnapshot(): Promise<Sources | null>;
     /**
      * These patches are on disk now: adopt what they produced as the committed
      * sources.
@@ -486,6 +507,28 @@ export declare abstract class ValOps {
         body: string;
         contentType: string;
     }>;
+    /**
+     * The proposal this server runs at the address of, or `null` on the site --
+     * and always in `fs` and memory mode, which have no proposals. See
+     * `ValProposal`.
+     */
+    currentProposal(): {
+        name: string;
+        branch: string;
+    } | null;
+    /**
+     * The content service's proposals API, for the Studio's switcher, list and
+     * dialogs. Refused here for the reason {@link publishApi} is: there is no
+     * content service to forward to. `profileId` is the person asking.
+     */
+    proposalsApi(_path: string, _init: {
+        method: string;
+        body?: string;
+    }, _profileId: string | null): Promise<{
+        status: number;
+        body: string;
+        contentType: string;
+    }>;
     /**
      * Whether a commit here produces `.val.ts` TEXT as well as data.
      *

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

@@ -1,3 +1,4 @@
+import { type ValProposal } from "./proposal.js";
 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, type PublishRefusal } from "./ValOps.js";
@@ -78,6 +79,8 @@ export declare class ValOpsHttp extends ValOps {
     private readonly publishJob;
     /** See `publishBuild` on {@link ValApiOptions}; sent with every position. */
     private readonly publishBuild;
+    /** See `proposal` on {@link ValApiOptions}; `null` on the site. */
+    private readonly proposal;
     /** Did the host hand over the running build's source? See `projectSource`. */
     embedsSource(): boolean;
     /**
@@ -148,6 +151,8 @@ export declare class ValOpsHttp extends ValOps {
         publishJob?: string;
         /** See `publishBuild` on {@link ValApiOptions}. */
         publishBuild?: string;
+        /** See `proposal` on {@link ValApiOptions}. */
+        proposal?: ValProposal;
     });
     /**
      * A deployment that cannot mirror a project which expects to be mirrored.
@@ -272,6 +277,35 @@ export declare class ValOpsHttp extends ValOps {
         body: string;
         contentType: string;
     }>;
+    currentProposal(): {
+        name: string;
+        branch: string;
+    } | null;
+    /**
+     * Which proposal calls the browser may make, by method and the path after
+     * `/proposals`: list and open, read and rename one, and close, reopen and
+     * retry its setup. Not `/save` -- the Studio saves through `/save`, which
+     * prepares the commit here -- and not `/patches`, which moves the site's
+     * changes into a proposal and has no screen yet.
+     */
+    private static proposalsApiAllowed;
+    /**
+     * What a proposal's address may reach of the publish API: building ITS OWN
+     * merge, and nothing that publishes the site's changes. The merge's prepare
+     * (content's, from the proposal's last save), the build it needs -- the
+     * site's build target and source, declaring and uploading the build -- and
+     * the job's own steps. Not a press of the site's Publish, not `next` (which
+     * would hand this tab a site job), and not the site job's prepare.
+     */
+    private static mergeApiPathAllowed;
+    proposalsApi(path: string, init: {
+        method: string;
+        body?: string;
+    }, profileId: string | null): Promise<{
+        status: number;
+        body: string;
+        contentType: string;
+    }>;
     /**
      * A publish job's prepare, sent to content: the job's sources, archived
      * there before the job is built (valbuild/home, docs/app-mode.md, "The
@@ -349,6 +383,19 @@ export declare class ValOpsHttp extends ValOps {
         unauthorized?: boolean;
         networkError?: boolean;
     }>;
+    /**
+     * Where this server sits in the content service's chain, as every request
+     * that asks about a position says it.
+     *
+     * In a proposal: its branch, and the save its snapshot is (none before the
+     * first). The content service then answers with what came after that save
+     * and nothing else -- never the site's position, which would replay the
+     * proposal's own saves over a snapshot that already holds them. Otherwise
+     * the commit this build was made from, or, for a build a tab made, its job.
+     */
+    private position;
+    /** The branch this server's patches are on, where it knows it. */
+    private ownBranch;
     getWebSocketNonce(profileId: string): Promise<{
         status: "success";
         data: {
@@ -458,6 +505,20 @@ export declare class ValOpsHttp extends ValOps {
      * cache: a second render a second later asks again.
      */
     private patchGroupsCache;
+    /**
+     * Forget the remembered group list, after a write through this server.
+     *
+     * A write changes membership -- a save joins its author's group, a delete or
+     * an unstage leaves it -- and the window above is long enough for the next
+     * render to be served the list from before it: an editor who saved and
+     * reloaded inside a second was shown their draft without the change they had
+     * just made. Called once the write has answered, so a read that started
+     * while it was in flight cannot leave the old list behind it.
+     *
+     * Only this instance's writes. Another instance's write is still seen at
+     * most one window late, which is what the window is for.
+     */
+    private forgetPatchGroups;
     getPatchGroups(options?: {
         /**
          * Ask the content API even if a recent answer is remembered.
@@ -493,6 +554,7 @@ export declare class ValOpsHttp extends ValOps {
      */
     private ownGroupBranch;
     private mutatePatchGroup;
+    private mutatePatchGroupRequest;
     protected saveSourceFilePatch(path: ModuleFilePath, patch: PatchT, patchId: PatchId, parentRef: ParentRefT, authorId: AuthorId | null, sessionId: string | null, patchGroup?: PatchGroupMembership): Promise<SaveSourceFilePatchResult>;
     /**
      * @deprecated For HTTP ops use direct upload instead (i.e. client should upload the files directly) since hosting platforms (Vercel) might have low limits on the size of the request body.

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

@@ -8,6 +8,7 @@ type Versions = {
     };
 };
 import type { ValPatchStore } from "./ValOpsMemory.js";
+import type { ValProposal } from "./proposal.js";
 import type { CommitContext, CommitResult } from "./ValServer.js";
 export type ValApiOptions = ValServerOverrides & ValConfig & Versions;
 type ValServerOverrides = Partial<{
@@ -156,6 +157,12 @@ type ValServerOverrides = Partial<{
      * one -- whose changes it does not hold, so they drop out of the overlay.
      */
     publishBuild?: string;
+    /**
+     * The proposal this server runs at the address of, when a platform serves
+     * one. See {@link ValProposal}: its branch, its position, its save route,
+     * and the snapshot that replaces the bundle's Source for what it saved.
+     */
+    proposal?: ValProposal;
     /**
      * The base url of Val.
      *

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

@@ -1,5 +1,6 @@
+import type { ValProposal } from "./proposal.js";
 import { ValModules, PatchId, ModuleFilePath, ValConfig } from "@valbuild/core";
-import { Api, ServerOf } from "@valbuild/shared/internal";
+import { Api, ServerOf, type PatchGroupT } from "@valbuild/shared/internal";
 import { z } from "zod";
 import { AuthorId, CommitSha, ValOps, type GenericErrorMessage, type PreparedCommit } from "./ValOps.js";
 import { ValOpsHttp } from "./ValOpsHttp.js";
@@ -145,6 +146,8 @@ export type ValServerConfig = ValServerOptions & ({
     publishJob?: string;
     /** See `publishBuild` on {@link ValApiOptions}. */
     publishBuild?: string;
+    /** See `proposal` on {@link ValApiOptions}. */
+    proposal?: ValProposal;
     config: ValConfig;
 }
 /**
@@ -261,6 +264,18 @@ chain: readonly {
  * `undefined` means "apply everything", which is what every caller that does
  * not ask for scoping gets and must keep getting.
  */
+/** The patches in this author's OPEN groups: what a scoped draft shows. */
+export declare function ownPatchIdsIn(patchGroups: PatchGroupT[], authorId: string): PatchId[];
+/**
+ * Whose pending patches a scoped draft shows, taken from the SAME response as
+ * the patches when it says, and from the list read beforehand only when not.
+ *
+ * See the call in `/sources/~`: the list read beforehand can be older than the
+ * chain, and the response's membership cannot be.
+ */
+export declare function ownPatchScopeFor(fetched: {
+    patchGroups?: PatchGroupT[];
+}, authorId: string | undefined, remembered: PatchId[] | undefined): PatchId[] | undefined;
 export declare function resolveOwnPatchScope(serverOps: ValOps, opts: {
     /** A caller that named a list already knows what it wants. */
     explicitPatchIds: PatchId[] | undefined;

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

@@ -2,6 +2,8 @@ export { createService, Service } from "./Service.js";
 export { defineExternal, ok, err, isExternalResult, EXTERNAL_RESULT, } from "./externalRecords.js";
 export type { AdapterFor, BoundExternalRecord, ExternalAuthor, ExternalBuilder, ExternalCtx, ExternalDefinition, ExternalFile, ExternalIssue, ExternalKeyPage, ExternalRecords, ExternalResult, ExternalSearchHit, ExternalSearchPage, ExternalSort, ItemOfModule, ReadonlyRecordHasNoWrites, Returns, } from "./externalRecords.js";
 export { createValApiRouter, createValServer, safeReadGit } from "./ValRouter.js";
+export { proposalFromEnv, proposalSnapshot } from "./proposal.js";
+export type { ValProposal } from "./proposal.js";
 export { initHandlerOptions, createValOps } from "./valServerConfig.js";
 export { resolveRemoteFileAuth } from "./valServerConfig.js";
 export { APP_MODE_REQUIRES_REMOTE_FILES } from "./valServerConfig.js";

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

@@ -0,0 +1,72 @@
+import type { Json, ModuleFilePath } from "@valbuild/core";
+/**
+ * A proposal this server runs at the address of: an editor-managed branch of
+ * the project's content, served from its own copy of the content the
+ * proposal has saved -- the **snapshot**. valbuild/home `docs/proposals.md`,
+ * "Saving".
+ *
+ * A third place Source can come from, beside the two Val already has:
+ *
+ * | source provider | Source comes from                      |
+ * | --------------- | -------------------------------------- |
+ * | committed       | the bundle                             |
+ * | draft           | content, pending patches applied       |
+ * | snapshot        | the proposal's saves                   |
+ *
+ * The snapshot REPLACES the bundle's Source for the modules the proposal has
+ * saved and nothing else, on every read: a committed render, the draft a page
+ * starts from, the Studio's tree, validation and the next save's prepare. The
+ * proposal's pending patches apply on top of it, as the site's apply on top of
+ * the bundle.
+ *
+ * Handed over by the platform that serves the address, per isolate: the
+ * snapshot only changes with a save, and a save is a new isolate.
+ */
+export type ValProposal = {
+    /** The proposal's name: twenty hex characters, the hash of its inputs. */
+    name: string;
+    /**
+     * The content branch the proposal's patches and saves are on
+     * (`val/p/<name>`). Sent wherever a request names a branch, so the patches
+     * this server reads and writes are the proposal's, never the site's.
+     */
+    branch: string;
+    /**
+     * The save the snapshot is, as a commit on {@link branch}; `null` before the
+     * first. Sent as this server's position, so the content service hands back
+     * only what came after it -- the snapshot already holds that save, and a
+     * save's patches applied twice would add every array item twice.
+     */
+    commit: string | null;
+    /**
+     * Saved Source, by module file path. As the platform parsed it: read it
+     * with {@link proposalSnapshot}, which checks that it is JSON.
+     */
+    modules: Record<string, unknown>;
+    /**
+     * Saved `.val.ts` text, by path with no leading slash, laid over the
+     * build's `projectSource`: the next save patches the text the last one
+     * wrote, not the text the base build was made from.
+     */
+    files: Record<string, string>;
+};
+/**
+ * The proposal a platform describes in its runtime env, or `undefined` when
+ * this is not a proposal's address.
+ *
+ * `VAL_PROPOSAL` and `VAL_BRANCH` name it; `VAL_OVERLAY` is the snapshot as
+ * JSON (`{ commit, modules, files }`). Throws on a snapshot that does not
+ * parse rather than serving the base build as though it were the proposal: a
+ * reviewer would be looking at the wrong content and nothing would say so.
+ */
+export declare function proposalFromEnv(env: {
+    VAL_PROPOSAL?: string | undefined;
+    VAL_BRANCH?: string | undefined;
+    VAL_OVERLAY?: string | undefined;
+}): ValProposal | undefined;
+/**
+ * The proposal's saved Source, as Source: every module whose value is JSON.
+ * One place, so the server and the readers that render without it agree on
+ * what the snapshot holds.
+ */
+export declare function proposalSnapshot(proposal: Pick<ValProposal, "modules">): Record<ModuleFilePath, Json>;