@valbuild/server 0.136.9 → 0.137.0

package/CHANGELOG.md

@@ -1,5 +1,86 @@
 # @valbuild/server
 
+## 0.137.0
+
+### Minor Changes
+
+- [#676](https://github.com/valbuild/val/pull/676) [`48ac9f0`](https://github.com/valbuild/val/commit/48ac9f06dd59a5b4ca60232b1ef198cf42f23aa6) Thanks [@freekh](https://github.com/freekh)! - A link-check endpoint, so the Studio can find out whether an external page is
+  still there.
+
+  `POST /external-urls/check` opens up to twenty URLs and reports what answered:
+  the final status after redirects, where it ended up, and how long it took. The
+  Studio's Check button in the external pages dialog is the only caller, and it
+  cannot do this itself — a cross-origin `fetch` from a browser cannot read a
+  response status without CORS headers no ordinary site sends.
+
+  It is an endpoint that makes outbound requests to addresses your content
+  supplies, so it is built as one:
+
+  - It is behind the same session check as every other authenticated route —
+    which, in fs mode, means the same anonymous access every other route allows
+    on a developer's own machine. It is not a new way in; it is the same door.
+  - It refuses to connect to anything that is not a public internet address —
+    loopback, link-local, the private ranges, the carrier-grade NAT range, and
+    the cloud metadata service that hands out instance credentials. The check is
+    on the RESOLVED address rather than the hostname, so a name that resolves to
+    `127.0.0.1` is refused, and it runs again at every redirect hop.
+  - It answers with one generic message for anything it refused, so the endpoint
+    cannot be used to find out what a hostname resolves to from inside your
+    network. The reason is logged on the server.
+  - `HEAD` first, `GET` only where a site answers 405 or 501 to it, and no
+    connection reuse between targets.
+
+- [#746](https://github.com/valbuild/val/pull/746) [`e2bfc0e`](https://github.com/valbuild/val/commit/e2bfc0e40383fe25d3ec0473d1032f6264a8939f) Thanks [@freekh](https://github.com/freekh)! - A site hosted on Val (a managed project, with no repository of its own) can now be updated from the Studio. **Settings → Updates** says whether a newer version of the software the site runs on is available, lists the packages that move and their versions, and offers **Update site**.
+
+  Updating rebuilds the site in the browser on the new versions and publishes it through the ordinary publish, so it is checked before it goes live: if the updated site does not render, nothing changes and the site keeps running the old versions. Unpublished changes are kept and are **not** published by an update. After it goes live, reload the Studio to use the new one.
+
+  In Safari, which cannot build the site in the Studio's own page, Update site opens a tab that builds and publishes it, the same way a publish does there, and the Studio follows its progress.
+
+  A Studio that was opened before the site was updated no longer publishes: pressing Publish asks you to reload first, and nothing is saved until you do. Your unpublished changes are kept. Without this, a Studio left open from before an update would have built the site with the previous version of itself.
+
+  The versions come from the template the project was made from, as the platform last built it. A project whose code lives in a repository is not offered this; its dependencies are updated there.
+
+  For hosts: `@valbuild/server` forwards `GET` and `POST /api/val/publish-api/update-target` to the content service, beside `/build-target` and `/project-source`.
+
+### Patch Changes
+
+- [#722](https://github.com/valbuild/val/pull/722) [`9b09bf3`](https://github.com/valbuild/val/commit/9b09bf38c9d5912f41fec1c18aa87455fd32f616) Thanks [@freekh](https://github.com/freekh)! - Show history for projects whose git branch is resolved by the server
+
+  A proxy-mode project that mirrors into a repository is committing to some
+  branch, and every commit and history listing is filed under it. But the Studio
+  reads `gitBranch` from `val.config` alone, where it is optional — so a project
+  that named its branch the usual deployment way (in the environment, e.g. from
+  `VERCEL_GIT_COMMIT_REF`) got a History pane reading "this project has no
+  `gitBranch` configured" and a status bar with no branch on it, while the server
+  behind it was busy committing to one.
+
+  `/stat` now fills in the branch the server resolved when `val.config` does not
+  name one. A branch in `val.config` still wins.
+
+  Nothing changes where there is no branch to name, and that is a real case
+  rather than a gap: git is optional in proxy mode — a project can run on
+  credentials alone, with no repository to mirror into — and `fs` mode has no
+  commits of its own. Those projects are handed no branch, and the Studio hides
+  what needs one rather than offering a History page that can only apologise.
+
+- [#748](https://github.com/valbuild/val/pull/748) [`beda04b`](https://github.com/valbuild/val/commit/beda04bd326cbab18ed103e8d43917b16f43bd8c) Thanks [@freekh](https://github.com/freekh)! - A save is no longer refused once because an older answer from the server arrived after a newer one. The content service now reports a version of its list of changes, which goes up with every save, discard and publish. The Studio ignores any answer older than one it already has, including the answer to its own last save, discard or publish, so a discarded change can no longer briefly come back, and a published one can no longer briefly show as unpublished.
+- Updated dependencies [[`8f60073`](https://github.com/valbuild/val/commit/8f60073e5490971a615cebbe8ea1243c67e43530), [`af7a4ba`](https://github.com/valbuild/val/commit/af7a4baa63da5d8a226166377a354cf2fc0c1d77), [`48ac9f0`](https://github.com/valbuild/val/commit/48ac9f06dd59a5b4ca60232b1ef198cf42f23aa6), [`daecf41`](https://github.com/valbuild/val/commit/daecf416f51990569a47a6a9ee9174b1a57f98c2), [`43b58f2`](https://github.com/valbuild/val/commit/43b58f2962840883badf91950da2c51b89d1c7cb), [`e2bfc0e`](https://github.com/valbuild/val/commit/e2bfc0e40383fe25d3ec0473d1032f6264a8939f), [`9b09bf3`](https://github.com/valbuild/val/commit/9b09bf38c9d5912f41fec1c18aa87455fd32f616), [`8e49bf4`](https://github.com/valbuild/val/commit/8e49bf41ad6a8ad3b01e502fb7ce0369baa316db), [`370d0df`](https://github.com/valbuild/val/commit/370d0df7ea45aeeafb4520318018d7c4e1c040d6), [`14877a8`](https://github.com/valbuild/val/commit/14877a85c5add4daa16836470b8739180a9fe8c6), [`beda04b`](https://github.com/valbuild/val/commit/beda04bd326cbab18ed103e8d43917b16f43bd8c)]:
+  - @valbuild/ui@0.137.0
+  - @valbuild/shared@0.137.0
+  - @valbuild/core@0.137.0
+
+## 0.136.10
+
+### Patch Changes
+
+- [#743](https://github.com/valbuild/val/pull/743) [`fef29b0`](https://github.com/valbuild/val/commit/fef29b0d9e826e4e7e63a3ae61553137a3f9d280) Thanks [@freekh](https://github.com/freekh)! - Saving no longer gets stuck on "Changes cannot be saved: something else keeps changing them first" when another editor has an unpublished change and later work has been published.
+
+  A new change is now written on top of the latest change the content service has registered, which it reports alongside the list of pending changes, instead of the last change this deployment was shown. Since changes can be published independently, those two can differ for good: an unpublished change can sit before published ones that the running deployment already contains. The Studio and the MCP tools both name the reported head, and fall back to the old behaviour against a content service that does not report one.
+
+- Updated dependencies [[`fef29b0`](https://github.com/valbuild/val/commit/fef29b0d9e826e4e7e63a3ae61553137a3f9d280)]:
+  - @valbuild/ui@0.136.10
+  - @valbuild/shared@0.136.10
+
 ## 0.136.9
 
 ### Patch Changes

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

@@ -141,6 +141,13 @@ export declare abstract class ValOps {
         commitSha?: CommitSha;
         sourcesSha: SourcesSha;
         patches: PatchId[];
+        /**
+         * The head of the chain, when the store reports one. See
+         * {@link OrderedPatches.headPatchId}.
+         */
+        headPatchId?: PatchId | null;
+        /** The chain version of that head. See {@link OrderedPatches.headVersion}. */
+        headVersion?: number;
     } | {
         type: "error";
         error: GenericErrorMessage;
@@ -396,6 +403,8 @@ export declare abstract class ValOps {
         createdAt: string;
         /** See {@link SaveSourceFilePatchResult} — absent where there are no groups. */
         patchGroupId?: string;
+        /** See {@link SaveSourceFilePatchResult}. */
+        headVersion?: number;
     }, {
         errorType: "other";
         error: GenericErrorMessage;
@@ -583,9 +592,12 @@ export declare abstract class ValOps {
         deleted: PatchId[];
         errors?: undefined;
         error?: undefined;
+        /** The chain version the delete moved the branch to, where reported. */
+        headVersion?: number;
     } | {
         deleted: PatchId[];
         errors: Record<PatchId, GenericErrorMessage>;
+        headVersion?: number;
     } | {
         error: GenericErrorMessage;
         errors?: undefined;
@@ -680,6 +692,12 @@ export type SaveSourceFilePatchResult = result.Result<{
      * client uses it to learn the id of the group its own first write created.
      */
     patchGroupId?: string;
+    /**
+     * The chain version this write made — see
+     * {@link OrderedPatches.headVersion}. Absent in `fs` mode and against a
+     * content service that predates it.
+     */
+    headVersion?: number;
 }, ({
     errorType: "other";
 } & GenericErrorMessage) | {
@@ -851,6 +869,28 @@ export type OrderedPatches = {
         } | null;
     }[];
     commits?: ValCommit[];
+    /**
+     * The head of the patch chain: the last patch registered on the branch,
+     * published or not. `null` when there is none.
+     *
+     * What a new patch names as its parent, and NOT the last of `patches` — see
+     * `chainHeadOf` in `@valbuild/shared` for why. Absent means the store does
+     * not report one: `ValOpsFS` (whose ordering log defines order, and which
+     * ignores the parent) and a content service that predates the field.
+     */
+    headPatchId?: PatchId | null;
+    /**
+     * The version of the chain {@link headPatchId} was read at.
+     *
+     * The content service bumps it with every write and every delete, in the
+     * transaction that makes the change, and reads it in the same statement as
+     * the head. `/stat` has more than one caller, so two answers can be in
+     * flight at once and land in either order; a client keeps the head with the
+     * highest version, and an answer that arrives after a newer one no longer
+     * puts its parent back. Absent wherever `headPatchId` is, and for the same
+     * reasons.
+     */
+    headVersion?: number;
     error?: GenericErrorMessage;
     errors?: PatchReadError[];
     unauthorized?: boolean;
@@ -862,6 +902,10 @@ export type OrderedPatchesMetadata = {
     })[];
     commits?: ValCommit[];
     deployments?: ValDeployment[];
+    /** See {@link OrderedPatches.headPatchId}. */
+    headPatchId?: OrderedPatches["headPatchId"];
+    /** See {@link OrderedPatches.headVersion}. */
+    headVersion?: OrderedPatches["headVersion"];
     error?: GenericErrorMessage;
     errors?: OrderedPatches["errors"];
     unauthorized?: boolean;

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

@@ -138,9 +138,11 @@ export declare class ValOpsFS extends ValOps {
         deleted: PatchId[];
         errors?: undefined;
         error?: undefined;
+        headVersion?: undefined;
     } | {
         deleted: PatchId[];
         errors: Record<PatchId, GenericErrorMessage>;
+        headVersion?: undefined;
     } | {
         error: GenericErrorMessage;
         errors?: undefined;

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

@@ -11,6 +11,15 @@ declare const CommitSha: z.ZodString & z.ZodType<CommitSha, string, z.core.$ZodT
 declare const BaseSha: z.ZodString & z.ZodType<BaseSha, string, z.core.$ZodTypeInternals<BaseSha, string>>;
 declare const AuthorId: z.ZodString & z.ZodType<AuthorId, string, z.core.$ZodTypeInternals<AuthorId, string>>;
 declare const ModuleFilePath: z.ZodString & z.ZodType<ModuleFilePath, string, z.core.$ZodTypeInternals<ModuleFilePath, string>>;
+/**
+ * This client's own branch's entry in a per-branch version map.
+ *
+ * A delete can span branches, so the content service answers per branch. With
+ * no branch of its own (a build with no repository, where the service resolves
+ * it), the only entry is ours when there is exactly one; with several, none can
+ * be picked, and a wrong one would floor this client at another chain's count.
+ */
+export declare function ownBranchVersion(headVersions: Record<string, number> | undefined, branch: string | undefined): number | undefined;
 export type PatchGroupMutationResult = {
     patchIds: PatchId[];
     status?: undefined;
@@ -197,7 +206,9 @@ export declare class ValOpsHttp extends ValOps {
      * An allow list rather than a prefix check, because this method holds a
      * credential and the browser chooses the path. `/publish/{id}` and its three
      * steps are the publish conversation; `/build-target` is what a build needs
-     * to know before it starts; `/project-source` is what it builds.
+     * to know before it starts; `/project-source` is what it builds;
+     * `/update-target` is the same question as `/build-target` for a managed
+     * project moving onto its template's current dependencies.
      *
      * `/project-source` is here rather than on a route of its own because it is
      * one of the three things a publish asks for and none of them are useful
@@ -256,6 +267,10 @@ export declare class ValOpsHttp extends ValOps {
         patches: PatchId[];
         /** Of `patches`, the ones that have shipped. See the implementation. */
         appliedPatches: PatchId[];
+        /** The head of the chain. See {@link OrderedPatchesMetadata.headPatchId}. */
+        headPatchId?: PatchId | null;
+        /** The chain version of that head. See {@link OrderedPatchesMetadata.headVersion}. */
+        headVersion?: number;
         /** The newest commit, which is the publish head. */
         headCommitSha?: string;
     } | {
@@ -425,9 +440,11 @@ export declare class ValOpsHttp extends ValOps {
         deleted: PatchId[];
         errors?: undefined;
         error?: undefined;
+        headVersion?: number;
     } | {
         deleted: PatchId[];
         errors: Record<PatchId, GenericErrorMessage>;
+        headVersion?: number;
     } | {
         error: GenericErrorMessage;
         errors?: undefined;
@@ -457,6 +474,8 @@ export declare class ValOpsHttp extends ValOps {
         /** See `CommitResult.tree`: absent means not reported. */
         tree?: string;
         branch: string;
+        /** The chain version the publish moved the branch to, where reported. */
+        headVersion?: number;
         error?: undefined;
     } | {
         isNotFastForward?: boolean;

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

@@ -108,6 +108,12 @@ export type CommitResult = {
      */
     tree?: string;
     branch: string;
+    /**
+     * The chain version the publish moved the branch to, where the content
+     * service versions its chain and the publish applied anything. Passed
+     * on to the Studio, so a `/stat` read before the publish is dropped.
+     */
+    headVersion?: number;
     error?: undefined;
 } | {
     isNotFastForward?: boolean;