@valbuild/server 0.135.0 → 0.136.1

package/CHANGELOG.md

@@ -1,5 +1,113 @@
 # @valbuild/server
 
+## 0.136.1
+
+### Patch Changes
+
+- [#716](https://github.com/valbuild/val/pull/716) [`4450be5`](https://github.com/valbuild/val/commit/4450be570ec3a66d7d98ba273c333ca2d2f163d9) Thanks [@freekh](https://github.com/freekh)! - `rebakeGit` rewires a project record to a different commit, and the Studio's publish proxy can now reach `/project-source`.
+
+  Both are groundwork for a publish that happens in the browser. `rebakeGit` replaces the one line in the generated `val.server.ts` that carries the commit, rather than regenerating the file: a publisher running inside the deployment does not know the project id or the platform's address, and reconstructing the file from what it could guess would throw away wiring it cannot see.
+
+- [#716](https://github.com/valbuild/val/pull/716) [`d2f385a`](https://github.com/valbuild/val/commit/d2f385a04978992a5036379235e447ba7775faef) Thanks [@freekh](https://github.com/freekh)! - The Studio works again when served from the published package, and a managed project's publish now puts the saved edit on the site.
+
+  - **The Studio did not start in 0.136.0.** Its main bundle imports sibling chunks by relative path, and the Studio is served at `/api/val/static/<version>/app`, so those imports resolved to paths the handler did not know and came back as the HTML fallback — which a browser refuses as a module script. Preview was gone with it. The handler now serves those chunks, and the package build follows every import the bundle makes before it lets a release through.
+  - **The in-browser builder could not load.** The Studio's bundle carried rolldown's Node WASI binding, which throws `process is not defined` in a tab. It now uses the browser binding, and the build refuses a bundle that contains the Node one.
+  - **A managed publish builds what was just saved.** `/save` returns the source files the commit wrote, the Studio builds with them laid over the project's stored source, and publishes that source back with the build — so the next edit starts from this one rather than undoing it. The save's commit is also passed through to the build, which previously ran as though no commit had been made.
+  - **The bundler's WebAssembly is served from `content.val.build/v1/static`** (`DEFAULT_STATIC_HOST`), still addressed by its SHA-256. `globalThis.__VAL_ROLLDOWN_WASM_URL__` still overrides it.
+  - The `val.server.ts` that `@valbuild/tanstack-build` generates no longer hands a save's files to the platform (`platform.internal/__api/source`). A managed project's Studio builds in its own tab, and the platform has closed that door. `isWired` recognises files wired either way.
+  - `@valbuild/tanstack-build/constants` exports the contract paths and the artifact key namespace from an entrypoint that imports nothing else, for callers that must not load the bundler. The namespace gains a `source` key.
+
+- Updated dependencies [[`cf89e74`](https://github.com/valbuild/val/commit/cf89e7429a79c4304ecbedd4f8b571a0de0f145f), [`c219574`](https://github.com/valbuild/val/commit/c21957498f3c7f4f47cef197c5dc0d591aa744ca), [`e673b43`](https://github.com/valbuild/val/commit/e673b43feaf48b7f30881d6786c858a0cb6a44a2), [`5c82928`](https://github.com/valbuild/val/commit/5c82928992d29f133f81cf0704a273c0449b18f1), [`d2f385a`](https://github.com/valbuild/val/commit/d2f385a04978992a5036379235e447ba7775faef)]:
+  - @valbuild/ui@0.136.1
+  - @valbuild/shared@0.136.1
+  - @valbuild/core@0.136.1
+
+## 0.136.0
+
+### Minor Changes
+
+- [#713](https://github.com/valbuild/val/pull/713) [`f3a4bb7`](https://github.com/valbuild/val/commit/f3a4bb7aea604943b92545c122243798c759715c) Thanks [@freekh](https://github.com/freekh)! - The Studio can load a bundler, and it stops telling a managed project that its
+  publish is on its way out.
+
+  **A managed project is one with no repository and no host watching one.** There
+  is nothing outside the browser to pick a commit up, so the Studio has been
+  showing it a story that belongs to a project with a repository: a `Building`
+  spinner, waiting for an event that can never arrive. It does not resolve on a
+  reload, on a retry, or tomorrow, and there is no way to tell it from a deploy
+  that is merely slow.
+
+  The content service now reports which kind of project this is, as `sourceMode`
+  on `/stat`, and the Studio narrates accordingly:
+
+  - a **connected** project keeps the deploy feed and keeps `Building`, because
+    there a host genuinely does pick the commit up;
+  - a **managed** one says `Saved, not yet live` instead — a durable condition,
+    not a phase, because nothing else will ever resolve it.
+
+  A server that reports no source mode keeps the behaviour it has today. Absence
+  means "not reported", never "managed": `fs` mode has no project to have a mode,
+  and neither does a content service that predates the field.
+
+  **The Studio also loads `@valbuild/tanstack-build` in the tab**, at mount and at
+  idle, for the managed projects that will need it — a browser that is the
+  deployer needs a bundler. This is the groundwork for browser-side publishing;
+  the publish path itself is unchanged in this release.
+
+  That bundler is `@rolldown/browser`, whose WebAssembly binary is 10.9 MB and is
+  **not** in the npm package. It is served from `static.val.build`, addressed by
+  the SHA-256 of its own bytes, so the build and the binary it needs cannot drift
+  apart. A deployment that must not reach that host — an air-gapped install, a
+  mirror — sets `globalThis.__VAL_ROLLDOWN_WASM_URL__` before the Studio loads and
+  needs no rebuild.
+
+  **Building in the browser requires a cross-origin isolated page.** Rolldown runs
+  WebAssembly on worker threads that share memory, and a browser will not hand a
+  `SharedArrayBuffer` to a worker otherwise. Without
+  `Cross-Origin-Opener-Policy: same-origin` and
+  `Cross-Origin-Embedder-Policy: require-corp` on the document Val is mounted in,
+  loading the bundler now fails with a message that says exactly that, instead of
+  a `DataCloneError` thrown from inside a worker. Nothing else in this release is
+  affected: a Studio that never builds in the browser never asks.
+
+### Patch Changes
+
+- [#699](https://github.com/valbuild/val/pull/699) [`1d72d00`](https://github.com/valbuild/val/commit/1d72d00a1b036959ae0f1540121701cbb2694dcb) Thanks [@freekh](https://github.com/freekh)! - A `*.val.ts` with no default export is no longer reported as a missing module
+
+  `*.val.ts` is a naming convention, not a promise: plenty of files under it hold
+  only the schemas and helpers the modules beside them import. Every one of those
+  was getting two errors in the editor — `Module '…' was not found in
+val.modules` and `… is not registered in val.modules, so Val will not serve it`
+  — both on line 1, telling their author to register a file that has nothing to
+  register. `val validate` has never reported them; only the editor did.
+
+  The default export is what makes a `*.val.ts` a module, so that is what the
+  diagnostic now asks about:
+
+  - **No default export → nothing is reported.** The file is not a module, so it
+    is not a module Val is failing to serve.
+  - **A default export → one diagnostic, on the `export default` itself** rather
+    than on line 1, so it is next to the thing that has to change, and the
+    duplicate fatal beside it is gone. The message now gives both remedies: add
+    the file to `val.modules`, or export what it holds by name instead. The "Val:
+    register … in val.modules" quick fix is offered there.
+
+  The rule is `findDefaultExport` in `@valbuild/server`, which `val validate`
+  already used to decide the same question — so the editor and the CLI now agree
+  about which files are modules, including the cases that are easy to get wrong
+  (`export * from …` carries no default; `export type { T as default }` and
+  `export default interface T {}` are both gone after transpilation).
+
+  Because the diagnostic now replaces a module's own findings rather than adding
+  to them, the editor also stops guessing about registration it cannot read: a
+  `val.modules` that registers modules through a tsconfig path alias
+  (`import("_/content/page.val")`), or that builds its list in another file, is no
+  longer taken to register nothing.
+
+- Updated dependencies [[`f3a4bb7`](https://github.com/valbuild/val/commit/f3a4bb7aea604943b92545c122243798c759715c)]:
+  - @valbuild/ui@0.136.0
+  - @valbuild/core@0.136.0
+  - @valbuild/shared@0.136.0
+
 ## 0.135.0
 
 ### Patch Changes

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

@@ -417,6 +417,47 @@ export declare abstract class ValOps {
      * project requires.
      */
     publishRefusal(): PublishRefusal | null;
+    /**
+     * How this project's SOURCE is kept, or `null` when it is nobody's question.
+     *
+     * `"managed"` -- the content service is the store of record, there is no
+     * repository, and nothing outside the browser will ever pick a commit up.
+     * `"connected"` -- commits are mirrored into a repository a host watches.
+     *
+     * `null` is the honest answer for `fs` and memory mode, where publishing is
+     * writing to disk and there is no project to have a mode, and for an `http`
+     * project whose content service predates the field. The Studio treats it as
+     * "the story I have always told", which is the connected one -- the feed, and
+     * a `building` state that something outside resolves. Guessing `managed`
+     * instead would take the deploy feed away from every project running against
+     * an older service.
+     */
+    sourceMode(): "managed" | "connected" | null;
+    /**
+     * Forward one call to the content service's publish API, as this project.
+     *
+     * The Studio builds a managed project in the tab and then has to publish what
+     * it built -- but a browser cannot talk to content directly. It holds a
+     * session cookie for THIS origin and no credential content would accept, so
+     * the conversation goes through here, exactly as patches already do.
+     *
+     * Refused by default, and that is the honest answer rather than a gap: `fs`
+     * and memory mode have no content service to forward to, and publishing there
+     * is writing to disk.
+     *
+     * The path is content's, minus the `/v1` prefix -- `/publish`,
+     * `/publish/{id}/artifacts`, `/build-target`. The ALLOW LIST lives in the
+     * implementation rather than here, because it is what keeps this from being
+     * a way to reach the rest of content with the project's credential.
+     */
+    publishApi(_path: string, _init: {
+        method: string;
+        body?: string;
+    }): 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

@@ -126,6 +126,82 @@ export declare class ValOpsHttp extends ValOps {
      * checking.
      */
     publishRefusal(): PublishRefusal | null;
+    /**
+     * What the content service last said this project's source mode is.
+     *
+     * Read off the same remembered expectation {@link publishRefusal} uses. It is
+     * CURRENT wherever it matters rather than a poll behind, and by construction
+     * rather than by luck: the only caller is `/stat`, which awaits `getStat`
+     * first, and that fetches the patches -- which is the response the expectation
+     * is recorded from.
+     *
+     * `null` before anything has fetched patches, which is the same "not
+     * reported" the wire field means, and reads as connected. The alternative
+     * would be to ask for it separately, which is a round trip for a field that
+     * has just arrived.
+     */
+    sourceMode(): "managed" | "connected" | null;
+    /**
+     * The short-lived publish token, and when it stops being usable.
+     *
+     * `null` until something publishes, which for most deployments is never.
+     */
+    private publishToken;
+    /**
+     * Trade this deployment's credential for one that can do one thing.
+     *
+     * Content's publish API takes a PROJECT TOKEN and nothing else --
+     * `authenticateProjectToken` refuses anything that is not one, deliberately,
+     * because a personal access token is a person's credential and does not name
+     * a project. What this deployment holds is the project's api key, which is
+     * neither.
+     *
+     * `POST /v1/{org}/{project}/publish-token` is the exchange, and it was built
+     * for exactly this: its own docblock names the case where "the caller was the
+     * project's api key ... a machine exchanging one machine credential for a
+     * narrower one". What comes back can publish one project for ten minutes.
+     *
+     * So the api key never leaves this process and the browser never sees any
+     * credential at all. That is the point of routing the publish through here
+     * rather than letting the tab talk to content.
+     */
+    private mintPublishToken;
+    /**
+     * A usable publish token, minting one when what we have will not last.
+     *
+     * The margin is what stops a token that is valid when the publish starts from
+     * expiring in the middle of it: a publish is five calls and an upload of
+     * every artifact, and the upload is the slow one.
+     */
+    private currentPublishToken;
+    /**
+     * The content paths this may reach, and nothing else.
+     *
+     * 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.
+     *
+     * `/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
+     * apart -- and because the credential is the same one. The Studio cannot get
+     * the project's files any other way: it runs inside the deployment, which
+     * holds a session for its own origin and an api key for content, and content
+     * is the only thing it is allowed to talk to at all.
+     *
+     * A publish id is opaque and content-generated, so it is matched rather than
+     * parsed -- what matters is that nothing with a `..`, a query or another
+     * segment gets through.
+     */
+    private static publishApiPathAllowed;
+    publishApi(path: string, init: {
+        method: string;
+        body?: string;
+    }): Promise<{
+        status: number;
+        body: string;
+        contentType: string;
+    }>;
     onInit(): Promise<void>;
     getPresignedAuthNonce(profileId: string, corsOrigin: string): Promise<{
         status: "success";

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

@@ -44,7 +44,7 @@ export type { ModulePathMap } from "./modulePathMap.js";
 export { ValOpsFS } from "./ValOpsFS.js";
 export { ValOpsHttp } from "./ValOpsHttp.js";
 export { ValOpsMemory, InMemoryPatchStore, type ValPatchStore, type StoredPatch, type ValOpsMemoryOptions, } from "./ValOpsMemory.js";
-export { loadValModules, createValModuleFileInspector } from "./loadValModules.js";
+export { loadValModules, createValModuleFileInspector, findDefaultExport, } from "./loadValModules.js";
 export type { ValModuleFileInspection } from "./loadValModules.js";
 export { formatPatchSourceError } from "./ValOps.js";
 export { compareWithCapturedReport, readCapturedReport, replaySnapshot, } from "./debug/replaySnapshot.js";

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

@@ -71,3 +71,26 @@ export type ValModuleFileInspection =
  * project's own first-party files.
  */
 export declare function createValModuleFileInspector(projectRoot: string, host?: ValModulesHost): (absPath: string) => ValModuleFileInspection;
+/**
+ * The statement that exports a RUNTIME value as `default`, without evaluating
+ * it — or `undefined` when the file has no such export.
+ *
+ * This is the one rule that separates a Val module from a `*.val.ts` that
+ * merely wears the naming convention: a shared schema or helper is exported by
+ * name, a module is exported by default. Every caller that needs to tell those
+ * apart goes through this — `val validate` to decide whether an unregistered
+ * file is worth reporting, and the language server to decide the same thing and
+ * to put its diagnostic on the export rather than on line 1.
+ *
+ * Two things deliberately do not count, because neither exists once the file is
+ * transpiled — and treating either as a default export would send a pure helper
+ * off to be evaluated and reported:
+ *
+ *  - `export * from "./x"`, since a star re-export never carries the default;
+ *  - a type-only export, in any of its three spellings
+ *    (`export type { T as default }`, `export { type T as default }` and
+ *    `export default interface T {}` — the last one parses as a declaration
+ *    carrying a `default` modifier, exactly like `export default class`, and is
+ *    the one that looks like a runtime export and is not).
+ */
+export declare function findDefaultExport(sourceFile: ts.SourceFile): ts.Statement | undefined;