@valbuild/shared 0.150.20 → 0.151.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (34) hide show
  1. package/CHANGELOG.md +236 -0
  2. package/client/dist/valbuild-shared-client.cjs.dev.js +1 -1
  3. package/client/dist/valbuild-shared-client.cjs.prod.js +1 -1
  4. package/client/dist/valbuild-shared-client.esm.js +1 -1
  5. package/dist/declarations/src/internal/ApiRoutes.d.ts +253 -2
  6. package/dist/declarations/src/internal/content/applyChain.d.ts +124 -0
  7. package/dist/declarations/src/internal/content/buildRegistry.d.ts +36 -0
  8. package/dist/declarations/src/internal/content/jsonValuesOps.d.ts +110 -0
  9. package/dist/declarations/src/internal/content/moduleStore.d.ts +119 -0
  10. package/dist/declarations/src/internal/content/source.d.ts +71 -0
  11. package/dist/declarations/src/internal/content/version.d.ts +151 -0
  12. package/dist/declarations/src/internal/index.d.ts +8 -1
  13. package/dist/declarations/src/internal/publish/projectSource.d.ts +28 -0
  14. package/dist/declarations/src/internal/search/searchIndex.d.ts +34 -3
  15. package/dist/declarations/src/internal/server/types.d.ts +9 -1
  16. package/dist/declarations/src/internal/valCanvasProtocol.d.ts +46 -0
  17. package/dist/declarations/src/internal/valClientHeader.d.ts +36 -0
  18. package/dist/declarations/src/publish/callJson.d.ts +15 -0
  19. package/dist/declarations/src/publish/jobClient.d.ts +7 -1
  20. package/dist/declarations/src/publish/publishClient.d.ts +2 -14
  21. package/dist/{getSitemapTree-fef55872.esm.js → getSitemapTree-3c1b9e57.esm.js} +18 -2
  22. package/dist/{getSitemapTree-6dfa2f4e.cjs.dev.js → getSitemapTree-59c5ed5d.cjs.dev.js} +18 -2
  23. package/dist/{getSitemapTree-8a04f3cf.cjs.prod.js → getSitemapTree-6b9024d1.cjs.prod.js} +18 -2
  24. package/dist/{protocol-d0efb8cd.cjs.dev.js → projectSource-2a58ef15.cjs.dev.js} +221 -0
  25. package/dist/{protocol-55cfa3cf.esm.js → projectSource-7f0ee83c.esm.js} +216 -1
  26. package/dist/{protocol-b1055ef0.cjs.prod.js → projectSource-ed6aec39.cjs.prod.js} +221 -0
  27. package/internal/dist/valbuild-shared-internal.cjs.dev.js +2387 -189
  28. package/internal/dist/valbuild-shared-internal.cjs.prod.js +2387 -189
  29. package/internal/dist/valbuild-shared-internal.esm.js +2332 -172
  30. package/package.json +3 -3
  31. package/publish/dist/valbuild-shared-publish.cjs.dev.js +48 -155
  32. package/publish/dist/valbuild-shared-publish.cjs.prod.js +48 -155
  33. package/publish/dist/valbuild-shared-publish.esm.js +17 -123
  34. package/dist/declarations/src/internal/server/requestScopedMemo.d.ts +0 -49
package/CHANGELOG.md CHANGED
@@ -1,5 +1,241 @@
1
1
  # @valbuild/shared
2
2
 
3
+ ## 0.151.0
4
+
5
+ ### Patch Changes
6
+
7
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`59faf33`](https://github.com/valbuild/val/commit/59faf332418af836617e09150fb89007e468394e) Thanks [@freekh](https://github.com/freekh)! - Code mode now works in a hosted Studio. In a proposal, the `</>` beside the
8
+ proposal's name turns code mode on for everyone in it, and the assistant can
9
+ then change the proposal's code. On the site, the `</>` lists the open
10
+ proposals and opens the one you choose with code mode on.
11
+
12
+ - **Nothing you typed is lost when code changes.** Turning code mode on saves
13
+ every pending change first, and so does each of the assistant's code
14
+ changes, so a field the assistant adds can be filled in and stays filled
15
+ in. Turning code mode off discards nothing.
16
+ - **Each person chooses what they see.** While code mode is on you can stay
17
+ in the content editor, or see the proposal's preview and its code changes.
18
+ The proposal's menu says who turned code mode on, and when.
19
+ - **The assistant asks.** With code mode off, its code tools refuse and say
20
+ who turned it off; it asks for code mode with a button in the chat instead.
21
+ - **Save is the one main button** in a proposal, and also updates the
22
+ preview when the code changed. Its menu holds **Commit**, in a project
23
+ connected to git, which puts the proposal on its git branch as one commit,
24
+ and **Publish**, which commits and then merges into the site. Both use the
25
+ project's commit message setting. In code mode, Save saves even when
26
+ content has validation errors; Publish is still refused until they are
27
+ fixed. If someone else pushed to the proposal's branch, Commit says who and
28
+ when, and links to their commit, instead of committing over it.
29
+ - The "schema changed, reload" dialog is not shown in code mode, where the
30
+ schema changes with every build.
31
+
32
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`abf6148`](https://github.com/valbuild/val/commit/abf6148a255abe795620fede66006462bccb8322) Thanks [@freekh](https://github.com/freekh)! - The assistant's code tools now see a publish of the site made while the Studio
33
+ is open. They read the site's code once and kept that copy for as long as the
34
+ page was open, so a file published in the meantime was shown as it was before.
35
+ They now ask on every call, and the content service answers "unchanged" without
36
+ sending the code again unless it did change.
37
+
38
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`1f08b65`](https://github.com/valbuild/val/commit/1f08b6517adeac27fd9e43c7bf726976daefee3b) Thanks [@freekh](https://github.com/freekh)! - Search and a library entry's "used by" no longer freeze the Studio on a large `.jsonValues()` record.
39
+
40
+ Both have to see every entry of the records they look in. The Studio used to ask for those entries one request at a time and rebuild the record after each one, which grew with the square of the record's size: about a second for 1,000 entries, and most of a minute for 10,000. Now:
41
+
42
+ - entries are requested many to a request (`GET /json` with a list of keys), with at most three such requests at a time, so what you open meanwhile is not queued behind them;
43
+ - what arrives is applied a batch at a time, with the browser free to handle clicks and typing between batches;
44
+ - search and "used by" show a progress bar with how many entries are loaded, show what they have found so far, and offer **Try again** if some entries could not be loaded;
45
+ - closing search or leaving the entry stops the requests that have not been sent;
46
+ - the search index adds only the entries that arrived, rather than re-reading the whole record each time.
47
+
48
+ A record's rows on screen are now also fetched in one request rather than one per row.
49
+
50
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`04bae7e`](https://github.com/valbuild/val/commit/04bae7e54e6b191fc70f45e6f10bbce820b6069c) Thanks [@freekh](https://github.com/freekh)! - **No more "A new version has been deployed" dialog.** A Studio that is open
51
+ while the site is deployed no longer stops you with a dialog you can only
52
+ answer by reloading. Instead:
53
+
54
+ - **On Val's hosting**, the Studio takes the new build's fields in where you
55
+ are, without reloading: a field the deploy added can be filled in at once,
56
+ and the assistant's chat, the page you were on and your unsaved edits stay
57
+ as they were. Each build now carries its content schemas as a small file of
58
+ its own beside its scripts, which the Studio loads.
59
+ - **Anywhere else** (a Next.js site, or a TanStack Start site hosted
60
+ somewhere else), the Studio reloads itself a few seconds after the deploy,
61
+ once everything you typed has been saved. Nothing is lost: where you were is
62
+ in the address, and every edit is on the server.
63
+ - **In local development** nothing changes: your dev server's hot reload
64
+ brings the new fields, as before.
65
+
66
+ When a deploy upgrades Val itself, the Studio reloads itself the same way,
67
+ since its own code changed too.
68
+
69
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`4fd35f3`](https://github.com/valbuild/val/commit/4fd35f321fe510cfb5b9b679ca14ce2b9e852d40) Thanks [@freekh](https://github.com/freekh)! - Unpublished edits are now applied the same way everywhere the server reads
70
+ them, and a few cases that showed something different from what Publish would
71
+ save are fixed:
72
+
73
+ - A field you emptied to `null`, `""`, `0` or `false` no longer jumps back to
74
+ its published value at your next edit.
75
+ - When an edit cannot be applied, later edits to `.jsonValues()` entries stop
76
+ there too, instead of showing an entry the page will never get.
77
+ - An image or file added to a `.jsonValues()` entry no longer fails the whole
78
+ entry when the upload comes before the field in the edit.
79
+ - Clearing a nullable `.jsonValues()` record removes its entries from drafts
80
+ as well.
81
+
82
+ Long chains of unpublished edits are also much faster to read: a draft with
83
+ 650 edits went from about 580 ms to about 110 ms.
84
+
85
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`346e6fd`](https://github.com/valbuild/val/commit/346e6fdc8e242bf826ab66a729eacd9f8d4be1a6) Thanks [@freekh](https://github.com/freekh)! - **Draft pages read what was edited, not the whole site.** A page in draft
86
+ mode used to make Val's server read every module, apply every pending
87
+ change, and preview and validate the whole project on every request -- and
88
+ then ask again for each `.jsonValues()` entry it showed. Now there is one
89
+ copy of the draft per process, made once per change and shared by every
90
+ editor and every request:
91
+
92
+ - A module nobody edited costs nothing: the page reads its own build, as a
93
+ visitor's does.
94
+ - A request asks one cheap question -- has anything changed? -- once, and
95
+ the draft is only re-read when it has. An edit is applied once, to the
96
+ version before it, however many pages read it afterwards.
97
+ - `fetchVal`, `fetchValKey`, `fetchValRoute`, `fetchValRouteUrl` and
98
+ `fetchValDraft` (Next.js and TanStack Start alike) and Val's API routes
99
+ read that one copy, so a save through the API is seen by every reader at
100
+ once. Before, each kept its own, and a publish moved only the copy of the
101
+ server that handled it: in a host that keeps its content in memory, a
102
+ draft page read through `fetchValKey` or `fetchValRoute` went on showing
103
+ the content from before the publish.
104
+ - The MCP tools (`initValMcp`) read the same copy in local development and
105
+ on Val's hosting, where Val's options come from your config and the
106
+ environment. `initValMcp` takes no patch store or source files of its
107
+ own, so in a host that keeps its content in memory it keeps a copy of its
108
+ own, as before.
109
+ - If `initValServer` and `initValContent` (or `initValRsc`) are given
110
+ different options for the same `val.modules` (a different patch store,
111
+ say), they keep separate copies, and Val logs a warning saying which
112
+ options differ.
113
+
114
+ On a site of 20 MB of content a draft read went from about half a second per
115
+ request to well under a millisecond once the draft is in memory, and the
116
+ memory it holds grows with what was edited rather than with the size of the
117
+ site. Hosted sites in proxy mode ask the content service one small question
118
+ per request instead of reading every pending change; with a content service
119
+ that predates it, Val reads the pending changes as before.
120
+
121
+ `ValDraft` (what `fetchValDraft` returns and `<ValProvider draft>` takes)
122
+ has a new optional `versions` field, filled in by the server: the page uses
123
+ it to tell that what the Studio sends is what it already shows, without
124
+ comparing the content. Nothing to change in your app.
125
+
126
+ **Changed:** `PUT /api/val/sources/~` no longer computes previews or
127
+ validates the content (the Studio does both itself, and `/api/val/validate`
128
+ checks a module on request); its `validate_sources` and
129
+ `validate_binary_files` flags are accepted and ignored.
130
+
131
+ **Deprecated, and removed in the next release.** These stay for one release
132
+ only so that a Studio, a page or a server of the previous release keeps
133
+ working while a deploy rolls out. Nothing in this release uses them; if
134
+ your own code calls any of them, move off it now:
135
+
136
+ - `PUT /api/val/sources/~`, the whole route. This release's Studio reads
137
+ `GET /api/val/manifest` and `GET /api/val/modules/~<path>`, and the draft
138
+ readers and MCP read in-process.
139
+ - The `source` field of the overlay's `source-update` event and the canvas's
140
+ `sourceUpdate` message, and a page's support for an event that carries
141
+ only `source` (this release sends `read` beside it).
142
+ - `ValDraft.base`: not sent and not read; the type stays one release so
143
+ code written against the previous one still compiles.
144
+ - `/api/val/stat`'s `sourcesSha` and `schemaSha`: the next release's Studio
145
+ stops depending on them, and the release after it stops sending them.
146
+
147
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`b0ad7f4`](https://github.com/valbuild/val/commit/b0ad7f496f2dc0384b8df847b1d77becf617b7bf) Thanks [@freekh](https://github.com/freekh)! - A draft page now catches up with an edit as soon as the server has it, instead
148
+ of on a timer.
149
+
150
+ - **The page settles faster, and without the 10 second fallback.** Content your
151
+ page reads on the server (a TanStack Start loader, a Next.js server component)
152
+ is refreshed when the editor's change has been saved, once per saved change.
153
+ It used to be refreshed the moment you typed — before the change was saved,
154
+ so the refresh often came back without it — and then again every 10 seconds
155
+ for half a minute in case it had. That safety refresh is gone, and so are the
156
+ extra requests it made while you edited. Another editor's change refreshes
157
+ the page too, once the server has it. While a deploy rolls out, a Studio of
158
+ the previous release (which never says it has saved) still refreshes the
159
+ page as each change arrives, as before.
160
+ - **Next.js: `ValProvider` takes an optional `draft` prop**, as
161
+ `@valbuild/tanstack`'s does: the editor's draft, read on the server for the
162
+ request. With it, the server renders the draft and the browser hydrates the
163
+ same thing, so a draft page no longer shows the published text first, and a
164
+ page that exists only as an unpublished change is found on the first render
165
+ instead of answering 404. Without it, nothing changes. See "The `draft` prop"
166
+ in the `@valbuild/next` README.
167
+ - **Next.js: `initValRsc` returns `fetchValDraft`**, which reads that draft:
168
+ pass `draft={await fetchValDraft()}` to `ValProvider` in your root layout. It
169
+ returns `null` unless the request is in draft mode, after one `draftMode()`
170
+ lookup and no other work, so visitors pay nothing and a static page stays
171
+ static. It reads the draft the way `@valbuild/tanstack/server`'s
172
+ `fetchValDraft` does and returns the same type, `ValDraft | null`, which
173
+ is now exported from `@valbuild/next` and `@valbuild/next/rsc` too.
174
+ - **`suspend` waits for the editor's changes properly.** With `suspend` on
175
+ `ValProvider`, a page could be told it had everything before the editor had
176
+ sent the pending change it needed, and render the published content first —
177
+ for a page that exists only as an unpublished change, a 404. It now waits
178
+ until the change is there.
179
+ - A draft page whose draft was discarded or published before the editor's
180
+ overlay or canvas connected now shows what the editor has, instead of keeping
181
+ the draft it was rendered with -- an edit inside a `.jsonValues()` entry
182
+ included.
183
+ - Turning draft mode on or off refreshes the page once. In development (React's
184
+ `StrictMode`) it could refresh twice, and Next.js could log "Cannot call
185
+ startTransition while rendering" while the page refreshed.
186
+
187
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`3aff85e`](https://github.com/valbuild/val/commit/3aff85e9a40cb0879285b86fd41fa8167db1bb5e) Thanks [@freekh](https://github.com/freekh)! - **A JSON Patch `test` op now fails when it does not hold.** A `test` op is a
188
+ precondition: "only apply this patch if the value at this path is still
189
+ this". Val used to accept every `test` op without checking it, so a patch
190
+ that should have been refused was applied anyway.
191
+
192
+ Now a `test` op fails its patch when the path does not exist, or when the
193
+ value there is not deeply equal to the one given (objects and arrays are
194
+ compared all the way down, and `0`, `""`, `false` and `null` are all
195
+ different from each other). The ops after it are not applied. This holds in
196
+ every place Val applies a patch -- the Studio's drafts, a draft page, the
197
+ content tools for MCP, and Publish -- so a patch a draft shows is a patch
198
+ Publish accepts.
199
+
200
+ Nothing in the Studio, the CLI or the content tools writes `test` ops of
201
+ its own, so this only changes anything for a patch you, or an agent through
202
+ the MCP `create_patch` tool, wrote with a `test` op in it: one whose test
203
+ does not hold is now refused with `Test failed` (or, for a path that does
204
+ not exist, `Path refers to non-existing object/array`) instead of applied.
205
+
206
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`809873c`](https://github.com/valbuild/val/commit/809873cd7dd2c17e261b7e92716397a6bb4d6e56) Thanks [@freekh](https://github.com/freekh)! - Every content reader in `@valbuild/next` and `@valbuild/tanstack` — `fetchVal`,
207
+ `useVal`, the key and route readers, on the server and in the browser — now
208
+ loads content the same way, so they can no longer disagree about which content
209
+ wins. Nothing you call changes. What you may notice:
210
+
211
+ - `useValRoute` on a `.jsonValues()` router loads only the entry for the
212
+ current route. It used to load every entry of the record first.
213
+ `useValRouteUrl` and `fetchValRouteUrl` load none at all: a URL does not need
214
+ them.
215
+ - In development, an edited `*.val.json` entry shows its new content after a
216
+ hot reload. The hooks kept the entry they had loaded before it.
217
+ - Next.js: `useValKey` no longer shows the published entry of a nullable
218
+ `.jsonValues()` record that a draft has set to `null`, nor anything for an
219
+ entry named like a built-in object property (such as `toString`) that the
220
+ draft does not have.
221
+ - With `suspend` on `ValProvider`, `useValKey` now waits for draft mode and the
222
+ editor's changes too, as `useVal` and `useValRoute` already did.
223
+ - When one entry of a `.jsonValues()` record cannot be loaded, `useVal` logs
224
+ the error and renders the others, as `fetchVal` already did, instead of
225
+ failing the whole component.
226
+
227
+ - [#1006](https://github.com/valbuild/val/pull/1006) [`4dc1481`](https://github.com/valbuild/val/commit/4dc1481cfb7cad4072bdbeaeb51b2b2ad43a9f5d) Thanks [@freekh](https://github.com/freekh)! - The Studio now shows each module as your server has it, by version, with only your own unsaved edits on top.
228
+
229
+ - **Publishing is faster.** After a publish, or when your site serves content published without a build, the Studio used to download every module's content before it showed anything new. It now reads only the modules that changed, one at a time: in our measurements with a 1,000-entry `.jsonValues()` record, the Studio was ready again after a publish in about 35 ms instead of 300–800 ms.
230
+ - **No flicker of old content on a draft page.** For up to a minute after a deploy, a request can still reach the build before it; that build now says it has been replaced (when Val's content service can tell it), and the Studio asks again rather than taking its content for the current one. In local development the same holds after you change a `.val.ts`: an answer from the code before the change is no longer taken for the new code's, so a page in draft mode no longer shows the new text, then the old, then the new again.
231
+ - **Another editor's change appears as your server has it.** The Studio no longer replays other people's changes on top of the content it loaded with, so a change made against a newer deployment can no longer show up twice or out of order.
232
+ - **Less sent with every draft page.** A page in draft mode no longer embeds the whole published content of a site served without a rebuild for the Studio to start from; `ValDraft.base` is deprecated and no longer filled in.
233
+ - **When the editor opens on a page that already shows your changes,** the Studio no longer sends them to the page again.
234
+
235
+ - [#1011](https://github.com/valbuild/val/pull/1011) [`4edd384`](https://github.com/valbuild/val/commit/4edd384cf04a25836df77aae6d88378f8750a761) Thanks [@freekh](https://github.com/freekh)! - Requests that `@valbuild/server` and the `val` CLI send to Val Build now carry an `x-val-client` header naming the package and its version, for example `x-val-client: @valbuild/server@0.150.24`. It lets Val Build see which versions are still in use, and which old endpoints they still call, before anything is retired. The header holds no credential and nothing about your site's visitors, and nothing changes in how your app behaves.
236
+ - Updated dependencies [[`a325152`](https://github.com/valbuild/val/commit/a325152856a881faec84c112fcf226828739f563), [`f5110c9`](https://github.com/valbuild/val/commit/f5110c9aa2a0a6ff0586e9f0f2a29eb1baef557d), [`3aff85e`](https://github.com/valbuild/val/commit/3aff85e9a40cb0879285b86fd41fa8167db1bb5e)]:
237
+ - @valbuild/core@0.151.0
238
+
3
239
  ## 0.150.20
4
240
 
5
241
  ### Patch Changes
@@ -2,7 +2,7 @@
2
2
 
3
3
  Object.defineProperty(exports, '__esModule', { value: true });
4
4
 
5
- var getSitemapTree = require('../../dist/getSitemapTree-6dfa2f4e.cjs.dev.js');
5
+ var getSitemapTree = require('../../dist/getSitemapTree-59c5ed5d.cjs.dev.js');
6
6
  require('../../dist/createForOfIteratorHelper-f2d7ac6d.cjs.dev.js');
7
7
  require('@valbuild/core');
8
8
 
@@ -2,7 +2,7 @@
2
2
 
3
3
  Object.defineProperty(exports, '__esModule', { value: true });
4
4
 
5
- var getSitemapTree = require('../../dist/getSitemapTree-8a04f3cf.cjs.prod.js');
5
+ var getSitemapTree = require('../../dist/getSitemapTree-6b9024d1.cjs.prod.js');
6
6
  require('../../dist/createForOfIteratorHelper-9ca2078d.cjs.prod.js');
7
7
  require('@valbuild/core');
8
8
 
@@ -1,3 +1,3 @@
1
- export { D as DEFAULT_CANVAS_SELECTION, e as DEFAULT_CANVAS_SELECTION_SOFT, Q as QUICK_PREVIEW_PARAM, v as QUICK_PREVIEW_RENDER_SCRIPT, u as QUICK_PREVIEW_SERVICE_WORKER_PATH, z as QUICK_PREVIEW_SERVICE_WORKER_SOURCE, x as QUICK_PREVIEW_STORE_MESSAGE, b as VAL_AI_SESSION_STORAGE_KEY, d as VAL_CANVAS_MESSAGE, c as VAL_CANVAS_PARAM, V as VAL_CONFIG_SESSION_STORAGE_KEY, a as VAL_THEME_SESSION_STORAGE_KEY, j as attachElementPicker, k as createPickerOverlay, h as describeElement, l as elementLabel, q as findBySelector, G as formatRoutePattern, H as getNextAppRouterSourceFolder, L as getPageRouterSitemapTree, J as getPageRouterSourceFolder, M as getPatternFromModuleFilePath, I as getTanStackRouterSourceFolder, E as isDesignTabOrigin, y as isQuickPreviewFiles, K as isTanStackRoutesFolder, g as isValCanvasFrame, i as isValCanvasPageMessage, f as isValCanvasStudioMessage, m as modifierLabel, p as pageLocationOf, F as parseRoutePattern, C as quickPreviewSiteOrigin, o as readPageSnapshot, r as restoreScroll, t as screenshotPage, s as startElementPicking, A as storeQuickPreview, n as watchPageLocation, B as withQuickPreviewParam, w as withValCanvasParam } from '../../dist/getSitemapTree-fef55872.esm.js';
1
+ export { D as DEFAULT_CANVAS_SELECTION, e as DEFAULT_CANVAS_SELECTION_SOFT, Q as QUICK_PREVIEW_PARAM, v as QUICK_PREVIEW_RENDER_SCRIPT, u as QUICK_PREVIEW_SERVICE_WORKER_PATH, z as QUICK_PREVIEW_SERVICE_WORKER_SOURCE, x as QUICK_PREVIEW_STORE_MESSAGE, b as VAL_AI_SESSION_STORAGE_KEY, d as VAL_CANVAS_MESSAGE, c as VAL_CANVAS_PARAM, V as VAL_CONFIG_SESSION_STORAGE_KEY, a as VAL_THEME_SESSION_STORAGE_KEY, j as attachElementPicker, k as createPickerOverlay, h as describeElement, l as elementLabel, q as findBySelector, G as formatRoutePattern, H as getNextAppRouterSourceFolder, L as getPageRouterSitemapTree, J as getPageRouterSourceFolder, M as getPatternFromModuleFilePath, I as getTanStackRouterSourceFolder, E as isDesignTabOrigin, y as isQuickPreviewFiles, K as isTanStackRoutesFolder, g as isValCanvasFrame, i as isValCanvasPageMessage, f as isValCanvasStudioMessage, m as modifierLabel, p as pageLocationOf, F as parseRoutePattern, C as quickPreviewSiteOrigin, o as readPageSnapshot, r as restoreScroll, t as screenshotPage, s as startElementPicking, A as storeQuickPreview, n as watchPageLocation, B as withQuickPreviewParam, w as withValCanvasParam } from '../../dist/getSitemapTree-3c1b9e57.esm.js';
2
2
  import '../../dist/createForOfIteratorHelper-9b80f1a2.esm.js';
3
3
  import '@valbuild/core';
@@ -512,6 +512,75 @@ export declare const Api: {
512
512
  }, z.core.$strip>]>;
513
513
  };
514
514
  };
515
+ /**
516
+ * What each module IS, right now: its version (`schema`, `base`, `chain`),
517
+ * and the project version that is relative to. What `/stat` answers, per
518
+ * module; see `docs/plans/one-content-model.md`, "The Studio loads
519
+ * everything from one place".
520
+ *
521
+ * It has its own ETag, so a client that sends it back (`If-None-Match`)
522
+ * gets a 304 and no body while nothing has moved. Computed from versions
523
+ * kept as content changes: answering it hashes nothing.
524
+ *
525
+ * "Since `seq` N" (`?since=N`, with the ETag of the manifest the client
526
+ * holds, which was answered at `seq` N, as `If-None-Match`): the modules
527
+ * whose version moved since that manifest, and no others, with `since: N`
528
+ * on the answer to say it is a delta. The ETag is in the body too (`tag`),
529
+ * for a client that reads answers through `ValClient`, which hands over
530
+ * the body and not the headers. Answered whole -- no `since` -- when the server no
531
+ * longer holds the manifest that ETag names (another process, another
532
+ * build, too long ago), and by a server of the release before, which
533
+ * ignores the parameter. Optional both ways.
534
+ */
535
+ "/manifest": {
536
+ GET: {
537
+ req: {
538
+ cookies: {
539
+ val_session: z.ZodOptional<z.ZodString>;
540
+ };
541
+ headers: {
542
+ "if-none-match": z.ZodOptional<z.ZodString>;
543
+ };
544
+ query: {
545
+ since: z.ZodOptional<z.ZodPipe<z.ZodArray<z.ZodString>, z.ZodTransform<string, string[]>>>;
546
+ };
547
+ };
548
+ res: z.ZodUnion<readonly [z.ZodObject<{
549
+ status: z.ZodLiteral<401>;
550
+ json: z.ZodObject<{
551
+ message: z.ZodString;
552
+ }, z.core.$strip>;
553
+ }, z.core.$strip>, z.ZodObject<{
554
+ status: z.ZodLiteral<500>;
555
+ json: z.ZodObject<{
556
+ message: z.ZodString;
557
+ }, z.core.$strip>;
558
+ }, z.core.$strip>, z.ZodObject<{
559
+ status: z.ZodLiteral<200>;
560
+ json: z.ZodObject<{
561
+ project: z.ZodObject<{
562
+ build: z.ZodString;
563
+ seq: z.ZodNumber;
564
+ }, z.core.$strip>;
565
+ modules: z.ZodRecord<z.ZodString & z.ZodType<ModuleFilePath, string, z.core.$ZodTypeInternals<ModuleFilePath, string>>, z.ZodObject<{
566
+ schema: z.ZodString;
567
+ base: z.ZodString;
568
+ chain: z.ZodString;
569
+ }, z.core.$strip>>;
570
+ tag: z.ZodOptional<z.ZodString>;
571
+ since: z.ZodOptional<z.ZodNumber>;
572
+ superseded: z.ZodOptional<z.ZodBoolean>;
573
+ registry: z.ZodOptional<z.ZodObject<{
574
+ entry: z.ZodString;
575
+ core: z.ZodString;
576
+ }, z.core.$strip>>;
577
+ }, z.core.$strip>;
578
+ }, z.core.$strip>, z.ZodObject<{
579
+ status: z.ZodLiteral<304>;
580
+ json: z.ZodOptional<z.ZodNull>;
581
+ }, z.core.$strip>]>;
582
+ };
583
+ };
515
584
  "/stat": {
516
585
  POST: {
517
586
  req: {
@@ -580,6 +649,10 @@ export declare const Api: {
580
649
  branch: z.ZodString;
581
650
  }, z.core.$strip>>;
582
651
  historyBranch: z.ZodOptional<z.ZodString>;
652
+ version: z.ZodOptional<z.ZodObject<{
653
+ build: z.ZodString;
654
+ seq: z.ZodNumber;
655
+ }, z.core.$strip>>;
583
656
  }, z.core.$strip>, z.ZodObject<{
584
657
  type: z.ZodLiteral<"use-websocket">;
585
658
  url: z.ZodString;
@@ -634,6 +707,10 @@ export declare const Api: {
634
707
  branch: z.ZodString;
635
708
  }, z.core.$strip>>;
636
709
  historyBranch: z.ZodOptional<z.ZodString>;
710
+ version: z.ZodOptional<z.ZodObject<{
711
+ build: z.ZodString;
712
+ seq: z.ZodNumber;
713
+ }, z.core.$strip>>;
637
714
  }, z.core.$strip>]>;
638
715
  }, z.core.$strip>]>;
639
716
  };
@@ -675,11 +752,17 @@ export declare const Api: {
675
752
  cookies: {
676
753
  val_session: z.ZodOptional<z.ZodString>;
677
754
  };
755
+ headers: {
756
+ "if-none-match": z.ZodOptional<z.ZodString>;
757
+ };
678
758
  };
679
- res: z.ZodObject<{
759
+ res: z.ZodUnion<readonly [z.ZodObject<{
680
760
  status: z.ZodNumber;
681
761
  json: z.ZodUnknown;
682
- }, z.core.$strip>;
762
+ }, z.core.$strip>, z.ZodObject<{
763
+ status: z.ZodLiteral<304>;
764
+ json: z.ZodOptional<z.ZodNull>;
765
+ }, z.core.$strip>]>;
683
766
  };
684
767
  POST: {
685
768
  req: {
@@ -1284,6 +1367,10 @@ export declare const Api: {
1284
1367
  errors: z.ZodOptional<z.ZodRecord<z.ZodString & z.ZodType<import("@valbuild/core").PatchId, string, z.core.$ZodTypeInternals<import("@valbuild/core").PatchId, string>>, z.ZodObject<{
1285
1368
  message: z.ZodString;
1286
1369
  }, z.core.$strip>>>;
1370
+ version: z.ZodOptional<z.ZodObject<{
1371
+ build: z.ZodString;
1372
+ seq: z.ZodNumber;
1373
+ }, z.core.$strip>>;
1287
1374
  }, z.core.$strip>;
1288
1375
  }, z.core.$strip>]>;
1289
1376
  };
@@ -1326,6 +1413,15 @@ export declare const Api: {
1326
1413
  }, z.core.$strip>]>;
1327
1414
  };
1328
1415
  };
1416
+ /**
1417
+ * @deprecated The whole tree. Nothing of this release asks it: the Studio
1418
+ * reads modules by version (`GET /manifest`, `GET /modules/~`), the draft
1419
+ * readers and MCP read the head in-process. Kept, with `exclude_patches`
1420
+ * (`BaseAlignment`'s fetch) and the ignored `validate_sources` and
1421
+ * `validate_binary_files`, for a Studio of the release before; goes in the
1422
+ * release after the one that ships this (see "Release-delayed deletions"
1423
+ * in `docs/plans/one-content-model.md`).
1424
+ */
1329
1425
  "/sources/~": {
1330
1426
  PUT: {
1331
1427
  req: {
@@ -1397,8 +1493,153 @@ export declare const Api: {
1397
1493
  fatal: z.ZodOptional<z.ZodBoolean>;
1398
1494
  fixes: z.ZodOptional<z.ZodArray<z.ZodType<"image:add-metadata" | "image:check-metadata" | "image:upload-remote" | "image:download-remote" | "image:check-remote" | "images:check-remote" | "images:upload-remote" | "file:add-metadata" | "file:check-metadata" | "file:upload-remote" | "file:download-remote" | "file:check-remote" | "files:check-remote" | "files:upload-remote" | "video:add-metadata" | "video:upload-remote" | "video:download-remote" | "videos:add-metadata" | "videos:check-remote" | "videos:upload-remote" | "keyof:check-keys" | "image:check-gallery" | "file:check-gallery" | "video:check-gallery" | "router:check-route" | "locale:check-locale" | "router:check-locale-param" | "images:check-unique-folder" | "files:check-unique-folder" | "images:check-all-files" | "files:check-all-files" | "videos:check-unique-folder" | "videos:check-all-files" | "jsonValues:extract-entry" | "record:fill-keys" | "external:upload" | "view:check-module" | "remote:rewrite-host", unknown, z.core.$ZodTypeInternals<"image:add-metadata" | "image:check-metadata" | "image:upload-remote" | "image:download-remote" | "image:check-remote" | "images:check-remote" | "images:upload-remote" | "file:add-metadata" | "file:check-metadata" | "file:upload-remote" | "file:download-remote" | "file:check-remote" | "files:check-remote" | "files:upload-remote" | "video:add-metadata" | "video:upload-remote" | "video:download-remote" | "videos:add-metadata" | "videos:check-remote" | "videos:upload-remote" | "keyof:check-keys" | "image:check-gallery" | "file:check-gallery" | "video:check-gallery" | "router:check-route" | "locale:check-locale" | "router:check-locale-param" | "images:check-unique-folder" | "files:check-unique-folder" | "images:check-all-files" | "files:check-all-files" | "videos:check-unique-folder" | "videos:check-all-files" | "jsonValues:extract-entry" | "record:fill-keys" | "external:upload" | "view:check-module" | "remote:rewrite-host", unknown>>>>;
1399
1495
  }, z.core.$strip>>>>;
1496
+ version: z.ZodOptional<z.ZodObject<{
1497
+ schema: z.ZodString;
1498
+ base: z.ZodString;
1499
+ chain: z.ZodString;
1500
+ }, z.core.$strip>>;
1501
+ }, z.core.$strip>>;
1502
+ project: z.ZodOptional<z.ZodObject<{
1503
+ build: z.ZodString;
1504
+ seq: z.ZodNumber;
1505
+ }, z.core.$strip>>;
1506
+ }, z.core.$strip>;
1507
+ }, z.core.$strip>]>;
1508
+ };
1509
+ };
1510
+ /**
1511
+ * One module by version: phase 6 of `docs/plans/one-content-model.md`
1512
+ * ("The Studio loads everything from one place"). `GET /modules/~<path>`,
1513
+ * with `v` the version wanted as its `moduleKey` (the newest when absent;
1514
+ * a base is a version with the empty chain) and `have` the version the
1515
+ * caller holds: when the caller's chain is a start of the answer's under
1516
+ * the same schema and base, the answer is the patches from it (`delta`),
1517
+ * otherwise the whole module. An answer for an asked `v` is immutable.
1518
+ */
1519
+ "/modules/~": {
1520
+ GET: {
1521
+ req: {
1522
+ path: z.ZodString;
1523
+ query: {
1524
+ v: z.ZodOptional<z.ZodPipe<z.ZodArray<z.ZodString>, z.ZodTransform<string, string[]>>>;
1525
+ have: z.ZodOptional<z.ZodPipe<z.ZodArray<z.ZodString>, z.ZodTransform<string, string[]>>>;
1526
+ };
1527
+ cookies: {
1528
+ val_session: z.ZodOptional<z.ZodString>;
1529
+ };
1530
+ };
1531
+ res: z.ZodUnion<readonly [z.ZodObject<{
1532
+ status: z.ZodLiteral<401>;
1533
+ json: z.ZodObject<{
1534
+ message: z.ZodString;
1535
+ }, z.core.$strip>;
1536
+ }, z.core.$strip>, z.ZodObject<{
1537
+ status: z.ZodLiteral<404>;
1538
+ json: z.ZodObject<{
1539
+ message: z.ZodString;
1540
+ current: z.ZodOptional<z.ZodObject<{
1541
+ schema: z.ZodString;
1542
+ base: z.ZodString;
1543
+ chain: z.ZodString;
1400
1544
  }, z.core.$strip>>;
1401
1545
  }, z.core.$strip>;
1546
+ }, z.core.$strip>, z.ZodObject<{
1547
+ status: z.ZodLiteral<500>;
1548
+ json: z.ZodObject<{
1549
+ message: z.ZodString;
1550
+ }, z.core.$strip>;
1551
+ }, z.core.$strip>, z.ZodObject<{
1552
+ status: z.ZodLiteral<200>;
1553
+ headers: z.ZodOptional<z.ZodObject<{
1554
+ "Cache-Control": z.ZodString;
1555
+ }, z.core.$strip>>;
1556
+ json: z.ZodUnion<readonly [z.ZodObject<{
1557
+ kind: z.ZodLiteral<"module">;
1558
+ version: z.ZodObject<{
1559
+ schema: z.ZodString;
1560
+ base: z.ZodString;
1561
+ chain: z.ZodString;
1562
+ }, z.core.$strip>;
1563
+ source: z.ZodAny;
1564
+ entries: z.ZodRecord<z.ZodString, z.ZodUnion<readonly [z.ZodObject<{
1565
+ content: z.ZodAny;
1566
+ version: z.ZodObject<{
1567
+ schema: z.ZodString;
1568
+ base: z.ZodString;
1569
+ chain: z.ZodString;
1570
+ key: z.ZodString;
1571
+ }, z.core.$strip>;
1572
+ }, z.core.$strip>, z.ZodObject<{
1573
+ deleted: z.ZodLiteral<true>;
1574
+ version: z.ZodObject<{
1575
+ schema: z.ZodString;
1576
+ base: z.ZodString;
1577
+ chain: z.ZodString;
1578
+ key: z.ZodString;
1579
+ }, z.core.$strip>;
1580
+ }, z.core.$strip>, z.ZodObject<{
1581
+ error: z.ZodString;
1582
+ patchId: z.ZodOptional<z.ZodString & z.ZodType<import("@valbuild/core").PatchId, string, z.core.$ZodTypeInternals<import("@valbuild/core").PatchId, string>>>;
1583
+ version: z.ZodObject<{
1584
+ schema: z.ZodString;
1585
+ base: z.ZodString;
1586
+ chain: z.ZodString;
1587
+ key: z.ZodString;
1588
+ }, z.core.$strip>;
1589
+ }, z.core.$strip>]>>;
1590
+ patches: z.ZodOptional<z.ZodArray<z.ZodString & z.ZodType<import("@valbuild/core").PatchId, string, z.core.$ZodTypeInternals<import("@valbuild/core").PatchId, string>>>>;
1591
+ failed: z.ZodOptional<z.ZodObject<{
1592
+ patchId: z.ZodString & z.ZodType<import("@valbuild/core").PatchId, string, z.core.$ZodTypeInternals<import("@valbuild/core").PatchId, string>>;
1593
+ message: z.ZodString;
1594
+ }, z.core.$strip>>;
1595
+ }, z.core.$strip>, z.ZodObject<{
1596
+ kind: z.ZodLiteral<"delta">;
1597
+ from: z.ZodObject<{
1598
+ schema: z.ZodString;
1599
+ base: z.ZodString;
1600
+ chain: z.ZodString;
1601
+ }, z.core.$strip>;
1602
+ to: z.ZodObject<{
1603
+ schema: z.ZodString;
1604
+ base: z.ZodString;
1605
+ chain: z.ZodString;
1606
+ }, z.core.$strip>;
1607
+ patches: z.ZodArray<z.ZodObject<{
1608
+ patchId: z.ZodString & z.ZodType<import("@valbuild/core").PatchId, string, z.core.$ZodTypeInternals<import("@valbuild/core").PatchId, string>>;
1609
+ patch: z.ZodArray<z.ZodDiscriminatedUnion<[z.ZodObject<{
1610
+ op: z.ZodLiteral<"add">;
1611
+ path: z.ZodArray<z.ZodString>;
1612
+ value: z.ZodType<import("@valbuild/core/patch").JSONValue, unknown, z.core.$ZodTypeInternals<import("@valbuild/core/patch").JSONValue, unknown>>;
1613
+ }, z.core.$strict>, z.ZodObject<{
1614
+ op: z.ZodLiteral<"remove">;
1615
+ path: z.ZodTuple<[z.ZodString], z.ZodString>;
1616
+ }, z.core.$strict>, z.ZodObject<{
1617
+ op: z.ZodLiteral<"replace">;
1618
+ path: z.ZodArray<z.ZodString>;
1619
+ value: z.ZodType<import("@valbuild/core/patch").JSONValue, unknown, z.core.$ZodTypeInternals<import("@valbuild/core/patch").JSONValue, unknown>>;
1620
+ }, z.core.$strict>, z.ZodObject<{
1621
+ op: z.ZodLiteral<"move">;
1622
+ from: z.ZodTuple<[z.ZodString], z.ZodString>;
1623
+ path: z.ZodArray<z.ZodString>;
1624
+ }, z.core.$strict>, z.ZodObject<{
1625
+ op: z.ZodLiteral<"copy">;
1626
+ from: z.ZodArray<z.ZodString>;
1627
+ path: z.ZodArray<z.ZodString>;
1628
+ }, z.core.$strict>, z.ZodObject<{
1629
+ op: z.ZodLiteral<"test">;
1630
+ path: z.ZodArray<z.ZodString>;
1631
+ value: z.ZodType<import("@valbuild/core/patch").JSONValue, unknown, z.core.$ZodTypeInternals<import("@valbuild/core/patch").JSONValue, unknown>>;
1632
+ }, z.core.$strict>, z.ZodObject<{
1633
+ op: z.ZodLiteral<"file">;
1634
+ path: z.ZodArray<z.ZodString>;
1635
+ filePath: z.ZodString;
1636
+ value: z.ZodType<import("@valbuild/core/patch").JSONValue, unknown, z.core.$ZodTypeInternals<import("@valbuild/core/patch").JSONValue, unknown>>;
1637
+ remote: z.ZodBoolean;
1638
+ nestedFilePath: z.ZodOptional<z.ZodArray<z.ZodString>>;
1639
+ metadata: z.ZodOptional<z.ZodType<import("@valbuild/core/patch").JSONValue, unknown, z.core.$ZodTypeInternals<import("@valbuild/core/patch").JSONValue, unknown>>>;
1640
+ }, z.core.$strict>], "op">>;
1641
+ }, z.core.$strip>>;
1642
+ }, z.core.$strip>]>;
1402
1643
  }, z.core.$strip>]>;
1403
1644
  };
1404
1645
  };
@@ -2259,6 +2500,11 @@ export declare const Api: {
2259
2500
  path: z.ZodString & z.ZodType<ModuleFilePath, string, z.core.$ZodTypeInternals<ModuleFilePath, string>>;
2260
2501
  key: z.ZodString;
2261
2502
  content: z.ZodAny;
2503
+ version: z.ZodOptional<z.ZodObject<{
2504
+ schema: z.ZodString;
2505
+ base: z.ZodString;
2506
+ chain: z.ZodString;
2507
+ }, z.core.$strip>>;
2262
2508
  }, z.core.$strip>;
2263
2509
  }, z.core.$strip>, z.ZodObject<{
2264
2510
  status: z.ZodLiteral<200>;
@@ -2276,6 +2522,11 @@ export declare const Api: {
2276
2522
  offset: z.ZodOptional<z.ZodNumber>;
2277
2523
  limit: z.ZodOptional<z.ZodNumber>;
2278
2524
  total: z.ZodOptional<z.ZodNumber>;
2525
+ version: z.ZodOptional<z.ZodObject<{
2526
+ schema: z.ZodString;
2527
+ base: z.ZodString;
2528
+ chain: z.ZodString;
2529
+ }, z.core.$strip>>;
2279
2530
  }, z.core.$strip>;
2280
2531
  }, z.core.$strip>, z.ZodObject<{
2281
2532
  status: z.ZodLiteral<400>;