@valbuild/shared 0.150.18 → 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.
- package/CHANGELOG.md +246 -0
- package/client/dist/valbuild-shared-client.cjs.dev.js +2 -1
- package/client/dist/valbuild-shared-client.cjs.prod.js +2 -1
- package/client/dist/valbuild-shared-client.esm.js +1 -1
- package/dist/declarations/src/internal/ApiRoutes.d.ts +253 -2
- package/dist/declarations/src/internal/content/applyChain.d.ts +124 -0
- package/dist/declarations/src/internal/content/buildRegistry.d.ts +36 -0
- package/dist/declarations/src/internal/content/jsonValuesOps.d.ts +110 -0
- package/dist/declarations/src/internal/content/moduleStore.d.ts +119 -0
- package/dist/declarations/src/internal/content/source.d.ts +71 -0
- package/dist/declarations/src/internal/content/version.d.ts +151 -0
- package/dist/declarations/src/internal/index.d.ts +8 -1
- package/dist/declarations/src/internal/publish/projectSource.d.ts +28 -0
- package/dist/declarations/src/internal/quickPreview.d.ts +17 -1
- package/dist/declarations/src/internal/search/searchIndex.d.ts +34 -3
- package/dist/declarations/src/internal/server/types.d.ts +9 -1
- package/dist/declarations/src/internal/valCanvasProtocol.d.ts +46 -0
- package/dist/declarations/src/internal/valClientHeader.d.ts +36 -0
- package/dist/declarations/src/publish/callJson.d.ts +15 -0
- package/dist/declarations/src/publish/jobClient.d.ts +7 -1
- package/dist/declarations/src/publish/publishClient.d.ts +2 -14
- package/dist/{getSitemapTree-7c848c94.esm.js → getSitemapTree-3c1b9e57.esm.js} +37 -4
- package/dist/{getSitemapTree-98642b57.cjs.dev.js → getSitemapTree-59c5ed5d.cjs.dev.js} +37 -3
- package/dist/{getSitemapTree-97713490.cjs.prod.js → getSitemapTree-6b9024d1.cjs.prod.js} +37 -3
- package/dist/{protocol-d0efb8cd.cjs.dev.js → projectSource-2a58ef15.cjs.dev.js} +221 -0
- package/dist/{protocol-55cfa3cf.esm.js → projectSource-7f0ee83c.esm.js} +216 -1
- package/dist/{protocol-b1055ef0.cjs.prod.js → projectSource-ed6aec39.cjs.prod.js} +221 -0
- package/internal/dist/valbuild-shared-internal.cjs.dev.js +2388 -189
- package/internal/dist/valbuild-shared-internal.cjs.prod.js +2388 -189
- package/internal/dist/valbuild-shared-internal.esm.js +2332 -172
- package/package.json +3 -3
- package/publish/dist/valbuild-shared-publish.cjs.dev.js +48 -155
- package/publish/dist/valbuild-shared-publish.cjs.prod.js +48 -155
- package/publish/dist/valbuild-shared-publish.esm.js +17 -123
- package/dist/declarations/src/internal/server/requestScopedMemo.d.ts +0 -49
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,251 @@
|
|
|
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
|
+
|
|
239
|
+
## 0.150.20
|
|
240
|
+
|
|
241
|
+
### Patch Changes
|
|
242
|
+
|
|
243
|
+
- [#998](https://github.com/valbuild/val/pull/998) [`c597b3b`](https://github.com/valbuild/val/commit/c597b3bcb9f3bbda285ab6f4977d65ed7f5f161d) Thanks [@freekh](https://github.com/freekh)! - **A quick preview now shows layout changes, not only text.** A quick preview loads the proposal's new code into a page the last build rendered on the server. React kept that page's markup wherever only attributes differed, so a change to classes (a layout made horizontal, a gap, a colour already in the site's styles) showed nothing, while a change to text did. The page is now rendered from the new code instead.
|
|
244
|
+
|
|
245
|
+
The design tab's assistant no longer offers `screenshot_page`, whose picture never came back from the page. `read_page` gives it the computed styles, sizes and positions it was for.
|
|
246
|
+
|
|
247
|
+
The assistant builds a proposal far less often. A quick preview shows components, layout, styles, text and content. It builds only for what a quick preview can't show, such as an added or renamed route, code that runs on the server, a schema or dependencies, and otherwise once, when a request is finished.
|
|
248
|
+
|
|
3
249
|
## 0.150.18
|
|
4
250
|
|
|
5
251
|
### Patch Changes
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
Object.defineProperty(exports, '__esModule', { value: true });
|
|
4
4
|
|
|
5
|
-
var getSitemapTree = require('../../dist/getSitemapTree-
|
|
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
|
|
|
@@ -11,6 +11,7 @@ require('@valbuild/core');
|
|
|
11
11
|
exports.DEFAULT_CANVAS_SELECTION = getSitemapTree.DEFAULT_CANVAS_SELECTION;
|
|
12
12
|
exports.DEFAULT_CANVAS_SELECTION_SOFT = getSitemapTree.DEFAULT_CANVAS_SELECTION_SOFT;
|
|
13
13
|
exports.QUICK_PREVIEW_PARAM = getSitemapTree.QUICK_PREVIEW_PARAM;
|
|
14
|
+
exports.QUICK_PREVIEW_RENDER_SCRIPT = getSitemapTree.QUICK_PREVIEW_RENDER_SCRIPT;
|
|
14
15
|
exports.QUICK_PREVIEW_SERVICE_WORKER_PATH = getSitemapTree.QUICK_PREVIEW_SERVICE_WORKER_PATH;
|
|
15
16
|
exports.QUICK_PREVIEW_SERVICE_WORKER_SOURCE = getSitemapTree.QUICK_PREVIEW_SERVICE_WORKER_SOURCE;
|
|
16
17
|
exports.QUICK_PREVIEW_STORE_MESSAGE = getSitemapTree.QUICK_PREVIEW_STORE_MESSAGE;
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
Object.defineProperty(exports, '__esModule', { value: true });
|
|
4
4
|
|
|
5
|
-
var getSitemapTree = require('../../dist/getSitemapTree-
|
|
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
|
|
|
@@ -11,6 +11,7 @@ require('@valbuild/core');
|
|
|
11
11
|
exports.DEFAULT_CANVAS_SELECTION = getSitemapTree.DEFAULT_CANVAS_SELECTION;
|
|
12
12
|
exports.DEFAULT_CANVAS_SELECTION_SOFT = getSitemapTree.DEFAULT_CANVAS_SELECTION_SOFT;
|
|
13
13
|
exports.QUICK_PREVIEW_PARAM = getSitemapTree.QUICK_PREVIEW_PARAM;
|
|
14
|
+
exports.QUICK_PREVIEW_RENDER_SCRIPT = getSitemapTree.QUICK_PREVIEW_RENDER_SCRIPT;
|
|
14
15
|
exports.QUICK_PREVIEW_SERVICE_WORKER_PATH = getSitemapTree.QUICK_PREVIEW_SERVICE_WORKER_PATH;
|
|
15
16
|
exports.QUICK_PREVIEW_SERVICE_WORKER_SOURCE = getSitemapTree.QUICK_PREVIEW_SERVICE_WORKER_SOURCE;
|
|
16
17
|
exports.QUICK_PREVIEW_STORE_MESSAGE = getSitemapTree.QUICK_PREVIEW_STORE_MESSAGE;
|
|
@@ -1,3 +1,3 @@
|
|
|
1
|
-
export { D as DEFAULT_CANVAS_SELECTION, e as DEFAULT_CANVAS_SELECTION_SOFT, Q as QUICK_PREVIEW_PARAM, u as QUICK_PREVIEW_SERVICE_WORKER_PATH,
|
|
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>;
|