@solidjs/web 2.0.0-beta.3 → 2.0.0-beta.30

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 (73) hide show
  1. package/README.md +27 -4
  2. package/dist/dev.cjs +1211 -205
  3. package/dist/dev.js +1175 -199
  4. package/dist/server.cjs +1342 -234
  5. package/dist/server.js +1304 -231
  6. package/dist/web.cjs +1195 -196
  7. package/dist/web.js +1159 -190
  8. package/frames/dist/client.cjs +1746 -0
  9. package/frames/dist/client.dev.cjs +1759 -0
  10. package/frames/dist/client.dev.js +1747 -0
  11. package/frames/dist/client.js +1734 -0
  12. package/frames/dist/server.cjs +2426 -0
  13. package/frames/dist/server.js +2414 -0
  14. package/frames/package.json +30 -0
  15. package/package.json +287 -38
  16. package/serialization/dist/serialization.cjs +169 -0
  17. package/serialization/dist/serialization.js +159 -0
  18. package/serialization/package.json +20 -0
  19. package/serialization/types/index.d.ts +157 -0
  20. package/serialization/types-cjs/index.d.cts +157 -0
  21. package/serialization/types-cjs/package.json +3 -0
  22. package/server-functions/dist/client.cjs +613 -0
  23. package/server-functions/dist/client.js +585 -0
  24. package/server-functions/dist/server.cjs +904 -0
  25. package/server-functions/dist/server.js +875 -0
  26. package/server-functions/package.json +30 -0
  27. package/storage/package.json +8 -3
  28. package/storage/types/index.d.ts +26 -0
  29. package/storage/types-cjs/index.d.cts +28 -0
  30. package/storage/types-cjs/package.json +3 -0
  31. package/types/client.d.ts +125 -21
  32. package/types/core.d.ts +4 -3
  33. package/types/frames/client.d.ts +20 -0
  34. package/types/frames/frame-client.d.ts +270 -0
  35. package/types/frames/frame-sink.d.ts +168 -0
  36. package/types/frames/frame-transport.d.ts +196 -0
  37. package/types/frames/serializer.d.ts +157 -0
  38. package/types/frames/server.d.ts +30 -0
  39. package/types/index.d.ts +211 -26
  40. package/types/jsx-properties.d.ts +93 -0
  41. package/types/jsx.d.ts +4150 -1
  42. package/types/response.d.ts +129 -0
  43. package/types/serializer.d.ts +157 -0
  44. package/types/server-functions/client.d.ts +200 -0
  45. package/types/server-functions/flash.d.ts +38 -0
  46. package/types/server-functions/server.d.ts +490 -0
  47. package/types/server-functions/shared.d.ts +445 -0
  48. package/types/server-mock.d.ts +93 -0
  49. package/types/server.d.ts +221 -28
  50. package/types-cjs/client.d.cts +192 -0
  51. package/types-cjs/core.d.cts +4 -0
  52. package/types-cjs/frames/client.d.cts +20 -0
  53. package/types-cjs/frames/frame-client.d.cts +270 -0
  54. package/types-cjs/frames/frame-sink.d.cts +168 -0
  55. package/types-cjs/frames/frame-transport.d.cts +196 -0
  56. package/types-cjs/frames/serializer.d.cts +157 -0
  57. package/types-cjs/frames/server.d.cts +30 -0
  58. package/types-cjs/index.d.cts +231 -0
  59. package/types-cjs/jsx-properties.d.cts +93 -0
  60. package/types-cjs/jsx.d.cts +4150 -0
  61. package/types-cjs/package.json +3 -0
  62. package/types-cjs/response.d.cts +129 -0
  63. package/types-cjs/serializer.d.cts +157 -0
  64. package/types-cjs/server-functions/client.d.cts +200 -0
  65. package/types-cjs/server-functions/flash.d.cts +38 -0
  66. package/types-cjs/server-functions/server.d.cts +490 -0
  67. package/types-cjs/server-functions/shared.d.cts +445 -0
  68. package/types-cjs/server-mock.d.cts +165 -0
  69. package/types-cjs/server.d.cts +349 -0
  70. package/storage/types/src/client.d.ts +0 -1
  71. package/storage/types/src/index.d.ts +0 -46
  72. package/storage/types/src/server-mock.d.ts +0 -72
  73. package/storage/types/storage/src/index.d.ts +0 -2
@@ -0,0 +1,490 @@
1
+ import { ResponseEnvelope } from "../response.js";
2
+ import { JSONCodecOptions } from "../serializer.js";
3
+ import { RequestEvent } from "../server.js";
4
+
5
+ export {
6
+ ERROR_HEADER,
7
+ FLASH_COOKIE,
8
+ FUNCTION_HEADER,
9
+ INSTANCE_HEADER,
10
+ SINGLE_FLIGHT_HEADER,
11
+ clearFlashCookie,
12
+ decodeErrorHeaderValue,
13
+ decodeResponse,
14
+ decodeResponsePayload,
15
+ encodeErrorHeaderValue,
16
+ getServerFunctionMetadata,
17
+ hasFlashCookie,
18
+ isServerFunction,
19
+ subscribeFlightData,
20
+ withMeta
21
+ } from "./shared.js";
22
+ export type {
23
+ FlightDataConsumer,
24
+ FlightDataContext,
25
+ ServerFunction,
26
+ ServerFunctionMetadata,
27
+ SingleFlightPayload
28
+ } from "./shared.js";
29
+ export { decodeFlashCookie, encodeFlashCookie } from "./flash.js";
30
+ export type { FlashSubmission } from "./flash.js";
31
+ import { ServerFunction } from "./shared.js";
32
+
33
+ /**
34
+ * The request event a server function call runs under: the base
35
+ * `RequestEvent` (request + locals) with `serverOnly` added, set when the
36
+ * call is an in-process SSR invocation whose result never serializes to a
37
+ * client.
38
+ */
39
+ export interface ServerFunctionEvent extends RequestEvent {
40
+ serverOnly?: boolean;
41
+ }
42
+
43
+ /**
44
+ * What a server function call resolved to, as seen by the single-flight
45
+ * hook — enough context for any data-production strategy without core
46
+ * assuming one.
47
+ */
48
+ export interface ServerFunctionOutcome {
49
+ /** The build-stable id of the function that ran. */
50
+ id: string;
51
+ /**
52
+ * The value the caller will receive: the raw return for plain results,
53
+ * the unwrapped `value` for `ResponseEnvelope`s, `null` for body-less
54
+ * control-flow `Response`s (redirect/reload).
55
+ */
56
+ value: unknown;
57
+ /**
58
+ * The `Response` carrying the result's HTTP metadata, when there is one
59
+ * (from a returned/thrown `Response` or a `ResponseEnvelope`). Read
60
+ * `Location` here for redirect-with-data — the data should describe the
61
+ * destination route — and `X-Revalidate` for the invalidated keys.
62
+ * Undefined for plain values.
63
+ */
64
+ response: Response | undefined;
65
+ /**
66
+ * The original HTTP request, untouched: headers the client integration
67
+ * sent (referrer, custom route context) ride here for the hook to read —
68
+ * core assigns them no meaning.
69
+ */
70
+ request: Request;
71
+ /** Whether the result was thrown rather than returned. */
72
+ thrown: boolean;
73
+ /**
74
+ * The URL the client will show after the mutation — the redirect
75
+ * `Location` when the outcome carries one (resolved against the request
76
+ * URL, as a browser would), the referring page otherwise. Undefined
77
+ * without a usable referer (a non-browser caller has no page to produce
78
+ * data for) and for redirects leaving the app's origin: produce no data
79
+ * when this is undefined.
80
+ */
81
+ targetUrl: string | undefined;
82
+ /**
83
+ * The outcome's `X-Revalidate` keys, split — the invalidation scope the
84
+ * mutation declared. Undefined when the outcome carries none (integrations
85
+ * typically collect everything for the target in that case).
86
+ */
87
+ revalidateKeys: string[] | undefined;
88
+ /**
89
+ * The request headers with the mutation's cookie effects applied: the
90
+ * event response's `Set-Cookie`s (set during the call), then the
91
+ * outcome's own (e.g. `redirect(to, { headers })`), later winning on
92
+ * conflict, deletions honored. Build the data-collection request from
93
+ * these so re-run reads observe post-mutation cookie state.
94
+ */
95
+ foldedHeaders: Headers;
96
+ }
97
+
98
+ /**
99
+ * The single-flight server hook: given the request event and the function's
100
+ * outcome, optionally produce a data payload (possibly async) to fold into
101
+ * the response alongside the return value. Data production is a black box
102
+ * to the protocol — render data-only, run route preloads, query a cache,
103
+ * whatever the integration chooses; the payload just has to be
104
+ * codec-serializable. Return undefined to send the response unchanged
105
+ * (byte-identical to a call without the hook).
106
+ *
107
+ * Runs after `transformResult`, only for scripted calls that sent
108
+ * `SINGLE_FLIGHT_HEADER` on the request, on returned results and thrown
109
+ * `Response`/`ResponseEnvelope` control-flow signals alike (plain thrown
110
+ * errors never collect, and neither do raw body-carrying `Response` values
111
+ * — those are the caller's verbatim payload). The handler owns the
112
+ * enveloping: contributed data ships as `{ value, data }` under the
113
+ * single-flight response header. The generic halves of collection arrive
114
+ * pre-digested on the outcome (`targetUrl`, `revalidateKeys`,
115
+ * `foldedHeaders`); the hook supplies only the data strategy.
116
+ */
117
+ export type CollectFlightDataHook = (
118
+ event: ServerFunctionEvent,
119
+ outcome: ServerFunctionOutcome
120
+ ) => unknown | Promise<unknown>;
121
+
122
+ /**
123
+ * Request headers with `setCookies` folded into the `Cookie` header, as the
124
+ * browser would have applied them before its next request. Later entries
125
+ * win on conflict, and deletions are honored (`Max-Age` at or below zero,
126
+ * `Expires` in the past). The input headers are not modified.
127
+ *
128
+ * For work re-run on the server after a mutation — a
129
+ * `CollectFlightDataHook` gathering fresh data, typically. That pass starts
130
+ * from the request that triggered the mutation, whose cookies are
131
+ * pre-mutation by definition, so a read depending on a session the mutation
132
+ * just established would otherwise see the old state. Which responses
133
+ * contribute their `Set-Cookie`s, and in what order, is the caller's
134
+ * decision.
135
+ *
136
+ * @example
137
+ * ```ts
138
+ * const headers = foldSetCookies(event.request.headers, [
139
+ * ...(event.response?.headers?.getSetCookie() ?? []),
140
+ * ...(outcome.response?.headers?.getSetCookie() ?? [])
141
+ * ]);
142
+ * ```
143
+ */
144
+ export function foldSetCookies(headers: Headers, setCookies: readonly string[]): Headers;
145
+
146
+ /** Options for `createNoJSHandler`. */
147
+ export interface NoJSHandlerOptions {
148
+ /** The app's mount path, for resolving a relative redirect `Location`. */
149
+ base?: string;
150
+ }
151
+
152
+ /**
153
+ * Builds the `handleNoJS` implementation for the no-JS form convention: a
154
+ * form posted without the client runtime has no way to receive a value, so
155
+ * the call redirects back to the referring page (or to the result's own
156
+ * `Location`, resolved against `base`) with the outcome riding a one-shot
157
+ * flash cookie. `303 See Other` turns the POST into a GET unless the result
158
+ * names a redirect status of its own. A result that is already a `Response`
159
+ * carries its meaning in its metadata and is not flashed.
160
+ *
161
+ * The render that follows reads the cookie with `decodeFlashCookie` and
162
+ * surfaces the outcome however it likes — that half is the integration's.
163
+ *
164
+ * The handler applies to every call it receives. `handleServerFunctionRequest`
165
+ * already uses it for browser form posts, so wire it explicitly only to set
166
+ * a `base`, or to extend the convention to direct HTTP calls by registering
167
+ * it through `configureServerFunctionsServer`.
168
+ */
169
+ export function createNoJSHandler(
170
+ options?: NoJSHandlerOptions
171
+ ): (result: unknown, request: Request, args: unknown[], thrown?: boolean) => Response;
172
+
173
+ /** Options for `configureServerFunctionsServer`. */
174
+ export interface ServerFunctionsServerConfig {
175
+ /**
176
+ * Establishes the request-event scope for a call — the function passed
177
+ * runs with `event` visible to `getRequestEvent()`. Wire it to
178
+ * `provideRequestEvent` from `@solidjs/web/storage` (or the framework's
179
+ * equivalent). When omitted, falls back to the AsyncLocalStorage instance
180
+ * an established request scope parks on the global.
181
+ */
182
+ provideEvent?: <T>(event: ServerFunctionEvent, fn: () => T) => T;
183
+ /**
184
+ * The single-flight hook: produces the data payload folded into
185
+ * responses of calls that opted in (see `CollectFlightDataHook`).
186
+ * Registered once by the integration that owns data production (a
187
+ * router); per-handler `collectFlightData` options override it.
188
+ */
189
+ collectFlightData?: CollectFlightDataHook;
190
+ /**
191
+ * Server-wide default for the handler's `transformResult` (same contract
192
+ * — see `HandleServerFunctionRequestOptions`); a per-request option
193
+ * overrides it. Registering it here makes result policies (e.g. frames'
194
+ * `frameTransformResult`) work through generic dispatchers that call
195
+ * `handleServerFunctionRequest(request)` with no options.
196
+ */
197
+ transformResult?(
198
+ event: ServerFunctionEvent,
199
+ result: unknown,
200
+ context: {
201
+ id: string;
202
+ args: unknown[];
203
+ instance: string | null;
204
+ request: Request;
205
+ thrown?: boolean;
206
+ }
207
+ ): unknown | ResponseEnvelope | Promise<unknown | ResponseEnvelope>;
208
+ /**
209
+ * `transformResult`'s counterpart for the single-flight fold: when a
210
+ * call's flight payload needs a body only a policy knows how to build
211
+ * (frames' `frameTransformFlightResult` — an invalidated entry is
212
+ * markup), this gets first refusal on the `{ value, data }` outcome.
213
+ * Return a `Response` to carry the outcome (call headers and cookies are
214
+ * copied onto it), or `undefined` to decline and keep the plain
215
+ * serialized envelope. A per-request option overrides it.
216
+ */
217
+ transformFlightResult?(
218
+ event: ServerFunctionEvent,
219
+ outcome: { value: unknown; data: unknown },
220
+ context: { id: string; args: unknown[]; instance: string | null; request: Request }
221
+ ): Response | undefined | Promise<Response | undefined>;
222
+ /**
223
+ * The in-process mirror of `transformResult` for direct (same-server)
224
+ * calls during document SSR — e.g. frames' `frameTransformDirectResult`.
225
+ */
226
+ transformDirectResult?(
227
+ value: unknown,
228
+ options: { id: string; args: unknown[]; event: ServerFunctionEvent }
229
+ ): unknown;
230
+ /**
231
+ * Server-wide response builder for calls made without the client runtime
232
+ * (see `handleNoJS` in `HandleServerFunctionRequestOptions`); a
233
+ * per-request option overrides it. Set it to `createNoJSHandler({ base })`
234
+ * to apply the convention to every non-scripted call rather than only to
235
+ * browser form posts, to a handler of your own to replace it, or to
236
+ * `null` to disable the built-in convention and answer form posts with
237
+ * the plain serialized response.
238
+ */
239
+ handleNoJS?:
240
+ | ((
241
+ result: unknown,
242
+ request: Request,
243
+ args: unknown[],
244
+ thrown?: boolean
245
+ ) => Response | Promise<Response>)
246
+ | null;
247
+ /**
248
+ * Endpoint the HTTP handler is mounted on, used for the `url` of SSR'd
249
+ * references (e.g. form actions) — must match the client configuration.
250
+ * Prefix it when the app serves from a base path (e.g.
251
+ * `` `${BASE_URL}_server` ``).
252
+ * @default "/_server"
253
+ */
254
+ endpoint?: string;
255
+ /**
256
+ * Codec options (extra plugins etc.) for decoding arguments and encoding
257
+ * results — must match the client's. Stored in the shared layer, so
258
+ * `decodeResponse` sees them too.
259
+ */
260
+ codec?: JSONCodecOptions;
261
+ }
262
+
263
+ /**
264
+ * Configures the server runtime. Call once at server startup, before
265
+ * handling requests. Only needed when deviating from the defaults (custom
266
+ * endpoint, codec plugins, an explicit event provider, or a single-flight
267
+ * hook).
268
+ */
269
+ export function configureServerFunctionsServer(config?: ServerFunctionsServerConfig): void;
270
+
271
+ /**
272
+ * A registered server function: its build-stable id paired with the
273
+ * original implementation. Returned by `registerServerReference` and
274
+ * consumed by the server-side `createServerReference`.
275
+ *
276
+ * Compiler ABI shape; hand-written code rarely constructs these.
277
+ * @internal
278
+ */
279
+ export interface ServerFunctionReference<T extends any[] = any[], R = any> {
280
+ id: string;
281
+ fn: (...args: T) => R;
282
+ /**
283
+ * The function's source name, emitted by development builds only —
284
+ * `createServerReference` seeds the metadata channel with it.
285
+ * @internal
286
+ */
287
+ name?: string;
288
+ }
289
+
290
+ /**
291
+ * Adds a function to the dispatch registry under an id and returns it
292
+ * unchanged. The low-level registry write for integrations registering
293
+ * functions outside the compiler (e.g. a router registering its own
294
+ * endpoints); compiled output goes through `registerServerReference`
295
+ * instead. Ids must be stable across the client and server builds.
296
+ */
297
+ export function registerServerFunction<T extends any[], R>(
298
+ id: string,
299
+ callback: (...args: T) => R
300
+ ): (...args: T) => R;
301
+
302
+ /**
303
+ * Looks up a registered server function by id; throws for unknown ids.
304
+ * The HTTP handler uses this for dispatch — integrations building custom
305
+ * dispatch (or introspection) can too.
306
+ */
307
+ export function getServerFunction<T extends any[], R>(id: string): (...args: T) => R;
308
+
309
+ /**
310
+ * Compiler ABI — emitted by compiled `"use server"` server output for
311
+ * every server function: registers `fn` for HTTP dispatch under its
312
+ * build-stable id and returns the reference the server-side
313
+ * `createServerReference` consumes. Development builds pass the function's
314
+ * source name as the trailing argument (dev-only metadata; never emitted in
315
+ * production). Not meant for hand-written code.
316
+ * @internal
317
+ */
318
+ export function registerServerReference<T extends any[], R>(
319
+ id: string,
320
+ fn: (...args: T) => R,
321
+ name?: string
322
+ ): ServerFunctionReference<T, R>;
323
+
324
+ /**
325
+ * Compiler ABI — emitted by compiled `"use server"` server output where
326
+ * the function was referenced; produces the server-side callable. Calling
327
+ * it during SSR runs the original function in-process (no HTTP), under a
328
+ * request event derived from the current one — marked `serverOnly` and
329
+ * carrying the function's meta. Not meant for hand-written code.
330
+ * @internal
331
+ */
332
+ export function createServerReference<T extends any[], R>(
333
+ reference: ServerFunctionReference<T, R>
334
+ ): (...args: T) => R;
335
+
336
+ /**
337
+ * Declares a server function callable over HTTP GET. The server half is
338
+ * identity-flavored — SSR calls stay in-process — but it brands the
339
+ * declaration on the reference's metadata channel
340
+ * (`getServerFunctionMetadata(fn)?.method === "GET"`) and records the
341
+ * declared method for the function's id so `handleServerFunctionRequest`
342
+ * honors it: GET-declared functions accept GET requests in addition to the
343
+ * default POST transport (declaring GET grants, it does not revoke);
344
+ * functions that never declared GET answer GET requests with 405.
345
+ *
346
+ * Wrap the reference at its declaration; the compiler round-trips the call
347
+ * in both builds:
348
+ *
349
+ * ```ts
350
+ * export const getUser = GET(async (id: string) => {
351
+ * "use server";
352
+ * return db.users.find(id);
353
+ * });
354
+ * ```
355
+ */
356
+ export function GET<A extends readonly any[], R>(
357
+ fn: (...args: A) => R
358
+ ): ServerFunction<A, Awaited<R>>;
359
+
360
+ /** Identity of the currently executing server function call. */
361
+ export interface ServerFunctionInvocation {
362
+ id: string;
363
+ }
364
+
365
+ /**
366
+ * Reads the in-flight server function invocation (its id) for the current
367
+ * request event — usable inside a server function body, e.g. to key caches
368
+ * or logs by function. Returns undefined outside a server function call.
369
+ * The state lives in a module-private WeakMap keyed by the per-call request
370
+ * event (never in `event.locals`, which derived events share with their
371
+ * outer event). Distinct from `getServerFunctionMetadata(fn)`, which reads
372
+ * a reference's static declaration metadata; this describes the call
373
+ * currently executing.
374
+ */
375
+ export function getServerFunctionInvocation(): ServerFunctionInvocation | undefined;
376
+
377
+ /**
378
+ * The event-keyed half of `getServerFunctionInvocation`, for callers handed
379
+ * an event outside its provideEvent scope (the handler's result transforms
380
+ * run after the scope has exited). Integration plumbing — application code
381
+ * reads the ambient accessor instead.
382
+ * @internal
383
+ */
384
+ export function getEventServerFunctionInvocation(
385
+ event: RequestEvent | undefined
386
+ ): ServerFunctionInvocation | undefined;
387
+
388
+ /**
389
+ * Hooks layering framework policy onto `handleServerFunctionRequest`.
390
+ * All are optional — the bare handler dispatches, scopes events, and
391
+ * encodes results on its own.
392
+ */
393
+ export interface HandleServerFunctionOptions {
394
+ /**
395
+ * Builds the request event a call runs under (default: bare
396
+ * `{ request, locals: {} }`). Integrations supply their richer event
397
+ * (cookies, response helpers, platform handles).
398
+ */
399
+ createEvent?(request: Request): ServerFunctionEvent;
400
+ /**
401
+ * Overrides the configured event provider for this handler — same
402
+ * contract as the `provideEvent` config option.
403
+ */
404
+ provideEvent?<T>(event: ServerFunctionEvent, fn: () => T): T;
405
+ /**
406
+ * Observes or replaces the function's result before encoding — the
407
+ * extension point for response metadata policies (headers, statuses,
408
+ * substituted results). Runs for returned and thrown results alike
409
+ * (`context.thrown` distinguishes); `context.instance` is null for no-JS
410
+ * calls. The context carries the call's identity — the function `id` and
411
+ * the parsed `args` the implementation was invoked with — matching the
412
+ * direct-call mirror (`transformDirectResult`), so a policy keying state
413
+ * by the call works over either dispatch path. Return the result
414
+ * unchanged to pass through, or a `ResponseEnvelope` (exposed through
415
+ * the core entry) to send HTTP metadata plus a structured payload. Runs
416
+ * before `collectFlightData`, so the flight hook sees the transformed
417
+ * outcome — use `collectFlightData`, not this, to fold data into the
418
+ * response.
419
+ */
420
+ transformResult?(
421
+ event: ServerFunctionEvent,
422
+ result: unknown,
423
+ context: {
424
+ id: string;
425
+ args: unknown[];
426
+ instance: string | null;
427
+ request: Request;
428
+ thrown?: boolean;
429
+ }
430
+ ): unknown | ResponseEnvelope | Promise<unknown | ResponseEnvelope>;
431
+ /**
432
+ * Overrides the configured single-flight hook for this handler — same
433
+ * contract as the `collectFlightData` config option (see
434
+ * `CollectFlightDataHook`).
435
+ */
436
+ collectFlightData?: CollectFlightDataHook;
437
+ /**
438
+ * Overrides the configured single-flight fold policy for this handler —
439
+ * same contract as the `transformFlightResult` config option.
440
+ */
441
+ transformFlightResult?(
442
+ event: ServerFunctionEvent,
443
+ outcome: { value: unknown; data: unknown },
444
+ context: { id: string; args: unknown[]; instance: string | null; request: Request }
445
+ ): Response | undefined | Promise<Response | undefined>;
446
+ /**
447
+ * Builds the response for calls made without the client runtime (no
448
+ * instance header — no-JS form posts, direct HTTP). Receives the
449
+ * (transformed) result, the request, and the decoded arguments; `thrown`
450
+ * is set when the result was thrown rather than returned.
451
+ *
452
+ * Overrides the configured hook, which in turn overrides the built-in
453
+ * `createNoJSHandler()` applied to browser form posts. Other
454
+ * no-instance callers get the normal serialized response.
455
+ */
456
+ handleNoJS?(
457
+ result: unknown,
458
+ request: Request,
459
+ args: unknown[],
460
+ thrown?: boolean
461
+ ): Response | Promise<Response>;
462
+ /** Overrides the configured codec options for this handler. */
463
+ codec?: JSONCodecOptions;
464
+ }
465
+
466
+ /**
467
+ * Web-standard HTTP handler for server function calls: resolves the
468
+ * function id from the request, gates GET dispatch on the declaration (405
469
+ * for a GET request to a function that never declared `GET`; POST is always
470
+ * accepted), decodes arguments, runs the function under a request-event scope,
471
+ * and encodes the result (forwarding redirect/revalidation metadata
472
+ * through headers). Mount it on the endpoint the client transport targets
473
+ * (default `/_server`); platform adapters (h3, express, ...) convert their
474
+ * request shape to a web `Request` around it.
475
+ *
476
+ * @example
477
+ * ```ts
478
+ * import { handleServerFunctionRequest } from "@solidjs/web/server-functions";
479
+ * import "virtual:solid-server-function-manifest";
480
+ *
481
+ * // in the server's request handling:
482
+ * if (url.pathname.startsWith("/_server")) {
483
+ * return handleServerFunctionRequest(request);
484
+ * }
485
+ * ```
486
+ */
487
+ export function handleServerFunctionRequest(
488
+ request: Request,
489
+ options?: HandleServerFunctionOptions
490
+ ): Promise<Response>;