@valbuild/server 0.139.2 → 0.140.0

package/CHANGELOG.md

@@ -1,5 +1,63 @@
 # @valbuild/server
 
+## 0.140.0
+
+### Minor Changes
+
+- [#769](https://github.com/valbuild/val/pull/769) [`cb93874`](https://github.com/valbuild/val/commit/cb938748aec15fd0ac3814c1696a2dd78ad63c27) Thanks [@freekh](https://github.com/freekh)! - The project name in the Studio's top bar is now a project switcher, for projects connected to Val Build. It shows the project you are in, the projects you pinned and the five you opened most recently, and searches every project in your organisations. Choosing one opens its Studio.
+
+  The top bar also gets a **Share** button (an icon on a phone). It shows who is in the project's organisation. Owners can create invite links for a role (each works once and expires after 7 days), see and revoke pending links, and change members' roles. Everyone else can see the members and which owners to ask.
+
+  The assistant can be set up from the Studio too. Settings › Assistant shows the AI key this project runs on and whether it works. From there you can add a key, update it, remove it, or choose one that already exists: the organisation's, your own, or another project's. The assistant's empty state offers the same when no key is set up. Every key is checked with the provider before it is saved, and once a key is saved the assistant turns on without a reload.
+
+  The panels are served by Val's content server (`content.val.build/wc/v1/project-switcher.js`, `members.js` and `ai-setup.js`), beside the API they read and write, so they can improve without a Val release. The Studio draws the project name and the Share button itself, and loads the switcher and Share panels only when the button is first hovered or clicked, so opening the Studio fetches nothing extra. If a panel cannot load, for example offline or under a strict Content Security Policy, the click opens the same page in Val Build instead, and the AI setup is a link to the project's AI keys there. If your app sets a CSP, allow `script-src https://content.val.build` to get them.
+
+  They reach Val Build through a new route on your app's Val server, `/api/val/admin/proxy/*`, which adds the editor's existing Val Build session. That route forwards only to the Studio API on Val's content server (`/v1/studio/*` on `VAL_CONTENT_URL`, `https://content.val.build` by default), and only with the `x-val-studio` header that a cross-site request cannot send.
+
+  In local development they appear once you have run `val login`, and use that login. Without one the Studio keeps the plain project name, as before; it does not load them just to say you are not logged in.
+
+### Patch Changes
+
+- [#793](https://github.com/valbuild/val/pull/793) [`092e6a7`](https://github.com/valbuild/val/commit/092e6a7f78bcfcf4c6cecaf34407fdfc580ebbc1) Thanks [@freekh](https://github.com/freekh)! - A draft page on TanStack Start is now rendered as the draft by the server, so it no longer shows the published text first and the draft a moment later — most noticeable when you reload right after publishing.
+
+  Read the request's draft in your site layout's loader and pass it to `ValProvider`:
+
+  ```tsx
+  // src/val/server.ts
+  export const { fetchValDraft /* , fetchVal, ... */ } = initValContent(
+    config,
+    valModules,
+    { draftMode },
+  );
+
+  // src/routes/_site.tsx
+  const getValDraft = createServerFn().handler(() => fetchValDraft());
+
+  export const Route = createFileRoute("/_site")({
+    loader: () => (typeof document === "undefined" ? getValDraft() : null),
+    component: SiteLayout,
+  });
+
+  function SiteLayout() {
+    const draft = Route.useLoaderData();
+    return (
+      <ValProvider config={config} suspend draft={draft}>
+        {/* ... */}
+      </ValProvider>
+    );
+  }
+  ```
+
+  Visitors pay one cookie lookup and nothing else. Without `draft`, pages behave as before. Edited `.jsonValues()` entries are rendered as the draft too; the others render from the build, as they do for visitors.
+
+  Also: a draft's `.jsonValues()` entries now include changes that were published after the build being served, instead of showing the old value until the next build is live.
+
+  Also: a renamed or duplicated `.jsonValues()` entry now has its content in the draft, on the page and when the Studio reads the entry, instead of failing to load until it is published.
+
+- Updated dependencies [[`cb93874`](https://github.com/valbuild/val/commit/cb938748aec15fd0ac3814c1696a2dd78ad63c27)]:
+  - @valbuild/ui@0.140.0
+  - @valbuild/shared@0.140.0
+
 ## 0.139.2
 
 ### Patch Changes

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

@@ -845,8 +845,10 @@ export type PatchReadError = {
  * 1. this module's, since the chain is branch-wide;
  * 2. this caller's, when they asked to be scoped. `undefined` is "everything",
  *    which is what every unscoped caller gets and must keep getting;
- * 3. not already applied — a fact about this path rather than about scoping,
- *    and true with or without a scope.
+ * 3. a patch published after this build is kept whatever the scope: it is
+ *    nobody's to hold back, and this build does not have it. One already in
+ *    the build is dropped. `draftOverlay` decides which is which, from
+ *    `commits`.
  *
  * Filtered here rather than by asking `fetchPatches` for a list, and that is
  * load-bearing: both implementations read an empty `patchIds` as "no filter"
@@ -862,7 +864,40 @@ export declare function scopedModulePatches<T extends {
     appliedAt: {
         commitSha: CommitSha;
     } | null;
-}>(patches: T[], moduleFilePath: ModuleFilePath, patchIds: PatchId[] | undefined): T[];
+}>(patches: T[], moduleFilePath: ModuleFilePath, patchIds: PatchId[] | undefined, 
+/** The commits content says came after this build: see `draftOverlay`. */
+commits?: Pick<ValCommit, "commitSha">[]): T[];
+/**
+ * The patches a DRAFT applies on top of this build's own source: the pending
+ * ones, and the ones published AFTER this build, in chain order -- with
+ * `appliedAt` cleared on the latter, because this build has none of them.
+ *
+ * Content places every caller at its own build (`getApplicablePatchesAndCommits`
+ * in valbuild/home: "the earliest the caller has not seen") and returns the
+ * commits after it as `commits`. A patch applied at one of those was
+ * published after this build and is not in it, so a draft has to apply it --
+ * skipping it showed the build's old value from the publish until the next
+ * build went live. `/sources/~` already applies them (`getSources` walks every
+ * patch it is given); the `.jsonValues()` entry path skipped them.
+ *
+ * A patch applied at a commit NOT in that list is already in this build --
+ * content returns one only because it was asked for by id -- and is dropped:
+ * applying it again would apply it twice. Without `commits` (a store that
+ * does not report them) every applied patch is dropped, as before. Only
+ * `ValOpsHttp` ever reports `appliedAt`; `fs` and memory stores report `null`.
+ *
+ * Chain order, not published-first, because that is the order the Studio
+ * applies them in, and a draft page starts from the server's answer and is
+ * then kept up to date by the Studio's: the two must agree.
+ *
+ * For the reads that render a draft only. What to COMMIT still keys on
+ * `appliedAt`: a published patch must never be published again.
+ */
+export declare function draftOverlay<T extends {
+    appliedAt: {
+        commitSha: CommitSha;
+    } | null;
+}>(patches: T[], commits: Pick<ValCommit, "commitSha">[] | undefined): T[];
 export type OrderedPatches = {
     patches: {
         path: ModuleFilePath;

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

@@ -165,7 +165,32 @@ export declare function applyJsonValuesEntryPatches(args: {
         patchId: PatchId;
         patch: Patch;
     }[];
+    /**
+     * The committed content of the OTHER entries of the record, for a
+     * whole-entry `move` or `copy` into this key: its content is the source
+     * entry's at that point in the chain, which is a different `*.val.json`.
+     *
+     * `undefined` for an entry the caller did not load, and then such an op is
+     * an error, as it is when this is not given at all. `{ content: undefined }`
+     * is an entry the committed source does not have.
+     */
+    baseContentOf?: (entryKey: string) => {
+        content: JSONValue | undefined;
+    } | undefined;
+    /**
+     * Replay only the ops before this one: patch index, then op index in it.
+     * How a move's source is read as it stood when the move was made.
+     */
+    stopBefore?: {
+        patch: number;
+        op: number;
+    };
 }): JsonEntryResolution;
+/**
+ * The entry a path names when it names a WHOLE entry of the root
+ * `.jsonValues()` record, and `undefined` for anything else.
+ */
+export declare function wholeEntryKey(serializedSchema: SerializedSchema | undefined, path: string[]): string | undefined;
 /**
  * Resolves an EXISTING entry's `*.val.json` path (relative to rootDir) from the
  * `import(...)` path recorded in the `.val.ts` thunk (from

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

@@ -118,5 +118,14 @@ export type ResolveRemoteFileAuthResult = {
     errorCode: "project-not-configured" | "pat-error" | "api-key-missing";
     message: string;
 };
+/**
+ * The personal access token `val login` wrote for this project, or null when
+ * there is none (or it does not parse). Only `fs` mode has a working directory
+ * to read it from, so every other mode answers null.
+ *
+ * Unlike `resolveRemoteFileAuth` this never answers with the api key: the
+ * caller wants to act as the DEVELOPER, and an api key is the project.
+ */
+export declare function readValLoginToken(options: ValServerConfig): Promise<string | null>;
 export declare function resolveRemoteFileAuth(options: ValServerConfig): Promise<ResolveRemoteFileAuthResult>;
 export {};