@torpor/build 0.4.14 → 1.0.0

package/dist/response.d.mts

@@ -1,351 +1,371 @@
+import { t as TypedResponse } from "./TypedResponse-6lznqN4U.mjs";
+import { t as Jsonify } from "./Jsonify-Dg6gChd3.mjs";
 //#region src/response/badRequest.d.ts
+type BadRequestResponse<T extends object | string | undefined> = T extends object ? TypedResponse<Jsonify<T>> : Response;
 /**
-* 400 Bad Request
-*
-* The HTTP 400 Bad Request client error response status code indicates that the
-* server would not process the request due to something the server considered
-* to be a client error. The reason for a 400 response is typically due to
-* malformed request syntax, invalid request message framing, or deceptive
-* request routing.
-*
-* Clients that receive a 400 response should expect that repeating the request
-* without modification will fail with the same error.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/400
-*/
-declare function badRequest(body?: object | string): Response;
+ * 400 Bad Request
+ *
+ * The HTTP 400 Bad Request client error response status code indicates that the
+ * server would not process the request due to something the server considered
+ * to be a client error. The reason for a 400 response is typically due to
+ * malformed request syntax, invalid request message framing, or deceptive
+ * request routing.
+ *
+ * Clients that receive a 400 response should expect that repeating the request
+ * without modification will fail with the same error.
+ *
+ * An object body is typed: it becomes the page's `$props.form` (with its JSON
+ * form) after a form submit, so validation errors can be surfaced with their
+ * field types via `PageForm`.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/400
+ */
+declare function badRequest<T extends object | string | undefined>(body?: T): BadRequestResponse<T>;
 //#endregion
 //#region src/response/created.d.ts
+type CreatedResponse<T extends object | string | undefined> = T extends object ? TypedResponse<Jsonify<T>> : Response;
 /**
-* 201 Created
-*
-* The HTTP 201 Created successful response status code indicates that the HTTP
-* request has led to the creation of a resource. This status code is commonly
-* sent as the result of a POST request.
-*
-* The new resource, or a description and link to the new resource, is created
-* before the response is returned. The newly-created items can be returned in
-* the body of the response message, but must be locatable by the URL of the
-* initiating request or by the URL in the value of the Location header provided
-* with the response.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/201
-*/
-declare function created(body?: object | string): Response;
+ * 201 Created
+ *
+ * The HTTP 201 Created successful response status code indicates that the HTTP
+ * request has led to the creation of a resource. This status code is commonly
+ * sent as the result of a POST request.
+ *
+ * The new resource, or a description and link to the new resource, is created
+ * before the response is returned. The newly-created items can be returned in
+ * the body of the response message, but must be locatable by the URL of the
+ * initiating request or by the URL in the value of the Location header provided
+ * with the response.
+ *
+ * An object body is typed: the client sees its JSON form through
+ * `makeApi`-created callers.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/201
+ */
+declare function created<T extends object | string | undefined>(body?: T): CreatedResponse<T>;
 //#endregion
 //#region src/response/forbidden.d.ts
 /**
-* 403 Forbidden
-*
-* The HTTP 403 Forbidden client error response status code indicates that the
-* server understood the request but refused to process it. This status is
-* similar to 401, except that for 403 Forbidden responses, authenticating or
-* re-authenticating makes no difference. The request failure is tied to
-* application logic, such as insufficient permissions to a resource or action.
-*
-* Clients that receive a 403 response should expect that repeating the request
-* without modification will fail with the same error. Server owners may decide
-* to send a 404 response instead of a 403 if acknowledging the existence of a
-* resource to clients with insufficient privileges is not desired.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403
-*/
+ * 403 Forbidden
+ *
+ * The HTTP 403 Forbidden client error response status code indicates that the
+ * server understood the request but refused to process it. This status is
+ * similar to 401, except that for 403 Forbidden responses, authenticating or
+ * re-authenticating makes no difference. The request failure is tied to
+ * application logic, such as insufficient permissions to a resource or action.
+ *
+ * Clients that receive a 403 response should expect that repeating the request
+ * without modification will fail with the same error. Server owners may decide
+ * to send a 404 response instead of a 403 if acknowledging the existence of a
+ * resource to clients with insufficient privileges is not desired.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403
+ */
 declare function forbidden(body?: object | string): Response;
 //#endregion
 //#region src/response/found.d.ts
 /**
-* 302 Found
-*
-* The HTTP 302 Found redirection response status code indicates that the
-* requested resource has been temporarily moved to the URL in the Location
-* header.
-*
-* A browser receiving this status will automatically request the resource at
-* the URL in the Location header, redirecting the user to the new page. Search
-* engines receiving this response will not attribute links to the original URL
-* to the new resource, meaning no SEO value is transferred to the new URL.
-*
-* > Note: In the Fetch Standard, when a user agent receives a 302 in response
-* > to a POST request, it uses the GET method in the subsequent redirection
-* > request, as permitted by the HTTP specification. To avoid user agents
-* > modifying the request, use 307 Temporary Redirect instead, as altering the
-* > method after a 307 response is prohibited.
-*
-* > In cases where you want any request method to be changed to GET, use 303
-* > See Other. This is useful when you want to give a response to a PUT method
-* > that is not the uploaded resource but a confirmation message such as: "you
-* > successfully uploaded XYZ".
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/302
-*/
-declare function permRedirect(location: string): Response;
+ * 302 Found
+ *
+ * The HTTP 302 Found redirection response status code indicates that the
+ * requested resource has been temporarily moved to the URL in the Location
+ * header.
+ *
+ * A browser receiving this status will automatically request the resource at
+ * the URL in the Location header, redirecting the user to the new page. Search
+ * engines receiving this response will not attribute links to the original URL
+ * to the new resource, meaning no SEO value is transferred to the new URL.
+ *
+ * > Note: In the Fetch Standard, when a user agent receives a 302 in response
+ * > to a POST request, it uses the GET method in the subsequent redirection
+ * > request, as permitted by the HTTP specification. To avoid user agents
+ * > modifying the request, use 307 Temporary Redirect instead, as altering the
+ * > method after a 307 response is prohibited.
+ *
+ * > In cases where you want any request method to be changed to GET, use 303
+ * > See Other. This is useful when you want to give a response to a PUT method
+ * > that is not the uploaded resource but a confirmation message such as: "you
+ * > successfully uploaded XYZ".
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/302
+ */
+declare function found(location: string): Response;
 //#endregion
 //#region src/response/methodNotAllowed.d.ts
 /**
-* 405 Method Not Allowed
-*
-* The HTTP 405 Method Not Allowed client error response status code indicates
-* that the server knows the request method, but the target resource doesn't
-* support this method. The server must generate an Allow header in a 405
-* response with a list of methods that the target resource currently supports.
-*
-* Improper server-side permissions set on files or directories may cause a 405
-* response when the request would otherwise be expected to succeed.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/405
-*/
+ * 405 Method Not Allowed
+ *
+ * The HTTP 405 Method Not Allowed client error response status code indicates
+ * that the server knows the request method, but the target resource doesn't
+ * support this method. The server must generate an Allow header in a 405
+ * response with a list of methods that the target resource currently supports.
+ *
+ * Improper server-side permissions set on files or directories may cause a 405
+ * response when the request would otherwise be expected to succeed.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/405
+ */
 declare function methodNotAllowed(body?: object | string): Response;
 //#endregion
 //#region src/response/movedPermanently.d.ts
 /**
-* 301 Moved Permanently
-*
-* The HTTP 301 Moved Permanently redirection response status code indicates
-* that the requested resource has been permanently moved to the URL in the
-* Location header.
-*
-* A browser receiving this status will automatically request the resource at
-* the URL in the Location header, redirecting the user to the new page. Search
-* engines receiving this response will attribute links to the original URL to
-* the redirected resource, passing the SEO ranking to the new URL.
-*
-* > Note: In the Fetch Standard, when a user agent receives a 301 in response
-* > to a POST request, it uses the GET method in the subsequent redirection
-* > request, as permitted by the HTTP specification. To avoid user agents
-* > modifying the request, use 308 Permanent Redirect instead, as altering the
-* > method after a 308 response is prohibited.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301
-*/
-declare function permRedirect$1(location: string): Response;
+ * 301 Moved Permanently
+ *
+ * The HTTP 301 Moved Permanently redirection response status code indicates
+ * that the requested resource has been permanently moved to the URL in the
+ * Location header.
+ *
+ * A browser receiving this status will automatically request the resource at
+ * the URL in the Location header, redirecting the user to the new page. Search
+ * engines receiving this response will attribute links to the original URL to
+ * the redirected resource, passing the SEO ranking to the new URL.
+ *
+ * > Note: In the Fetch Standard, when a user agent receives a 301 in response
+ * > to a POST request, it uses the GET method in the subsequent redirection
+ * > request, as permitted by the HTTP specification. To avoid user agents
+ * > modifying the request, use 308 Permanent Redirect instead, as altering the
+ * > method after a 308 response is prohibited.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301
+ */
+declare function movedPermanently(location: string): Response;
 //#endregion
 //#region src/response/notFound.d.ts
 /**
-* 404 Not Found
-*
-* The HTTP 404 Not Found client error response status code indicates that the
-* server cannot find the requested resource. Links that lead to a 404 page are
-* often called broken or dead links and can be subject to link rot.
-*
-* A 404 status code only indicates that the resource is missing without
-* indicating if this is temporary or permanent. If a resource is permanently
-* removed, servers should send the 410 Gone status instead.
-*
-* 404 errors on a website can lead to a poor user experience for your visitors,
-* so the number of broken links (internal and external) should be minimized to
-* prevent frustration for readers. Common causes of 404 responses are mistyped
-* URLs or pages that are moved or deleted without redirection. For more
-* information, see the Redirections in HTTP guide.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/404
-*/
+ * 404 Not Found
+ *
+ * The HTTP 404 Not Found client error response status code indicates that the
+ * server cannot find the requested resource. Links that lead to a 404 page are
+ * often called broken or dead links and can be subject to link rot.
+ *
+ * A 404 status code only indicates that the resource is missing without
+ * indicating if this is temporary or permanent. If a resource is permanently
+ * removed, servers should send the 410 Gone status instead.
+ *
+ * 404 errors on a website can lead to a poor user experience for your visitors,
+ * so the number of broken links (internal and external) should be minimized to
+ * prevent frustration for readers. Common causes of 404 responses are mistyped
+ * URLs or pages that are moved or deleted without redirection. For more
+ * information, see the Redirections in HTTP guide.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/404
+ */
 declare function notFound(body?: object | string): Response;
 //#endregion
 //#region src/response/notModified.d.ts
 /**
-* 304 Not Modified
-*
-* The HTTP 304 Not Modified redirection response status code indicates that
-* there is no need to retransmit the requested resources.
-*
-* This response code is sent when the request is a conditional GET or HEAD
-* request with an If-None-Match or an If-Modified-Since header and the
-* condition evaluates to 'false'. It confirms that the resource cached by the
-* client is still valid and that the server would have sent a 200 OK response
-* with the resource if the condition evaluated to 'true'. See HTTP caching for
-* more information.
-*
-* The response must not contain a body and must include the headers that would
-* have been sent in an equivalent 200 response, such as:
-*
-* - Cache-Control
-* - Content-Location
-* - Date
-* - ETag
-* - Expires
-* - Vary
-*
-* > Note: Many developer tools' network panels of browsers create extraneous
-* > requests leading to 304 responses, so that access to the local cache is
-* > visible to developers.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/304
-*/
-declare function notModified(location: string): Response;
+ * 304 Not Modified
+ *
+ * The HTTP 304 Not Modified redirection response status code indicates that
+ * there is no need to retransmit the requested resources.
+ *
+ * This response code is sent when the request is a conditional GET or HEAD
+ * request with an If-None-Match or an If-Modified-Since header and the
+ * condition evaluates to 'false'. It confirms that the resource cached by the
+ * client is still valid and that the server would have sent a 200 OK response
+ * with the resource if the condition evaluated to 'true'. See HTTP caching for
+ * more information.
+ *
+ * The response must not contain a body and must include the headers that would
+ * have been sent in an equivalent 200 response, such as:
+ *
+ * - Cache-Control
+ * - Content-Location
+ * - Date
+ * - ETag
+ * - Expires
+ * - Vary
+ *
+ * > Note: Many developer tools' network panels of browsers create extraneous
+ * > requests leading to 304 responses, so that access to the local cache is
+ * > visible to developers.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/304
+ */
+declare function notModified(): Response;
 //#endregion
 //#region src/response/ok.d.ts
+type OkResponse<T extends object | string | undefined> = T extends object ? TypedResponse<Jsonify<T>> : Response;
 /**
-* 200 OK
-*
-* The HTTP 200 OK successful response status code indicates that a request has
-* succeeded. A 200 OK response is cacheable by default.
-*
-* A 200 OK response has a different meaning and format depending on the HTTP
-* request method. Here's how they vary for different methods:
-*
-* - GET: A resource was retrieved by the server and included in the response
-*   body.
-* - POST: An action succeeded; the response has a message body describing the
-*   result.
-* - HEAD: Identical to GET, except there is no message body.
-* - TRACE: The response has a message body containing the request as received
-*   by the server.
-*
-* Although possible, successful PUT or DELETE requests often do not result in a
-* 200 OK response. It is more common to see 201 Created if the resource is
-* uploaded or created for the first time, or 204 No Content upon successful
-* deletion of a resource.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200
-*/
-declare function ok(body?: object | string): Response;
+ * 200 OK
+ *
+ * The HTTP 200 OK successful response status code indicates that a request has
+ * succeeded. A 200 OK response is cacheable by default.
+ *
+ * A 200 OK response has a different meaning and format depending on the HTTP
+ * request method. Here's how they vary for different methods:
+ *
+ * - GET: A resource was retrieved by the server and included in the response
+ *   body.
+ * - POST: An action succeeded; the response has a message body describing the
+ *   result.
+ * - HEAD: Identical to GET, except there is no message body.
+ * - TRACE: The response has a message body containing the request as received
+ *   by the server.
+ *
+ * Although possible, successful PUT or DELETE requests often do not result in
+ * a 200 OK response. It is more common to see 201 Created if the resource is
+ * uploaded or created for the first time, or 204 No Content upon successful
+ * deletion of a resource.
+ *
+ * An object body is typed: the client sees its JSON form through
+ * `makeApi`-created callers.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200
+ */
+declare function ok<T extends object | string | undefined>(body?: T): OkResponse<T>;
 //#endregion
 //#region src/response/permanentRedirect.d.ts
 /**
-* 308 Permanent Redirect
-*
-* The HTTP 308 Permanent Redirect redirection response status code indicates
-* that the requested resource has been permanently moved to the URL given by
-* the Location header.
-*
-* A browser receiving this status will automatically request the resource at
-* the URL in the Location header, redirecting the user to the new page. Search
-* engines receiving this response will attribute links to the original URL to
-* the redirected resource, passing the SEO ranking to the new URL.
-*
-* The request method and the body will not be modified by the client in the
-* redirected request. A 301 Moved Permanently requires the request method and
-* the body to remain unchanged when redirection is performed, but this is
-* incorrectly handled by older clients to use the GET method instead.
-*
-* > Note: Some Web applications may use the 308 Permanent Redirect in a
-* > non-standard way and for different purposes. For example, Google Drive uses
-* > a 308 Resume Incomplete response to indicate to the client when an
-* > unfinished upload has stalled. See Perform a resumable download on the
-* > Google Drive documentation for more information.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308
-*/
+ * 308 Permanent Redirect
+ *
+ * The HTTP 308 Permanent Redirect redirection response status code indicates
+ * that the requested resource has been permanently moved to the URL given by
+ * the Location header.
+ *
+ * A browser receiving this status will automatically request the resource at
+ * the URL in the Location header, redirecting the user to the new page. Search
+ * engines receiving this response will attribute links to the original URL to
+ * the redirected resource, passing the SEO ranking to the new URL.
+ *
+ * The request method and the body will not be modified by the client in the
+ * redirected request. A 301 Moved Permanently requires the request method and
+ * the body to remain unchanged when redirection is performed, but this is
+ * incorrectly handled by older clients to use the GET method instead.
+ *
+ * > Note: Some Web applications may use the 308 Permanent Redirect in a
+ * > non-standard way and for different purposes. For example, Google Drive uses
+ * > a 308 Resume Incomplete response to indicate to the client when an
+ * > unfinished upload has stalled. See Perform a resumable download on the
+ * > Google Drive documentation for more information.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308
+ */
 declare function permanentRedirect(location: string): Response;
 //#endregion
 //#region src/response/response.d.ts
 /**
-* Creates a response with the supplied status code and optional body.
-*
-* If the body is an object, it will be converted to JSON and the content-type
-* header set to "application/json". Otherwise, if the body is a string, the
-* content-type header will be set to "text/plain".
-*/
+ * Creates a response with the supplied status code and optional body.
+ *
+ * If the body is an object, it will be converted to JSON and the Content-Type
+ * header set to "application/json". Otherwise, if the body is a string, the
+ * Content-Type header will be set to "text/plain".
+ */
 declare function response(status: number, body?: object | string): Response;
 //#endregion
 //#region src/response/seeOther.d.ts
 /**
-* 303 See Other
-*
-* The HTTP 303 See Other redirection response status code indicates that the
-* browser should redirect to the URL in the Location header instead of
-* rendering the requested resource.
-*
-* This response code is often sent back as a result of PUT or POST methods so
-* the client may retrieve a confirmation, or view a representation of a
-* real-world object (see HTTP range-14). The method to retrieve the redirected
-* resource is always GET.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/303
-*/
+ * 303 See Other
+ *
+ * The HTTP 303 See Other redirection response status code indicates that the
+ * browser should redirect to the URL in the Location header instead of
+ * rendering the requested resource.
+ *
+ * This response code is often sent back as a result of PUT or POST methods so
+ * the client may retrieve a confirmation, or view a representation of a
+ * real-world object (see HTTP range-14). The method to retrieve the redirected
+ * resource is always GET.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/303
+ */
 declare function seeOther(location: string): Response;
 //#endregion
 //#region src/response/serverError.d.ts
 /**
-* 500 Server Error
-*
-* The HTTP 500 Internal Server Error server error response status code
-* indicates that the server encountered an unexpected condition that prevented
-* it from fulfilling the request. This error is a generic "catch-all" response
-* to server issues, indicating that the server cannot find a more appropriate
-* 5XX error to respond with.
-*
-* If you're a visitor seeing 500 errors on a web page, these issues require
-* investigation by server owners or administrators. There are many possible
-* causes of 500 errors, including: improper server configuration, out-of-memory
-* (OOM) issues, unhandled exceptions, improper file permissions, or other
-* complex factors. Server administrators may proactively log occurrences of
-* server error responses, like the 500 status code, with details about the
-* initiating requests to improve the stability of a service in the future.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/500
-*/
+ * 500 Server Error
+ *
+ * The HTTP 500 Internal Server Error server error response status code
+ * indicates that the server encountered an unexpected condition that prevented
+ * it from fulfilling the request. This error is a generic "catch-all" response
+ * to server issues, indicating that the server cannot find a more appropriate
+ * 5XX error to respond with.
+ *
+ * If you're a visitor seeing 500 errors on a web page, these issues require
+ * investigation by server owners or administrators. There are many possible
+ * causes of 500 errors, including: improper server configuration, out-of-memory
+ * (OOM) issues, unhandled exceptions, improper file permissions, or other
+ * complex factors. Server administrators may proactively log occurrences of
+ * server error responses, like the 500 status code, with details about the
+ * initiating requests to improve the stability of a service in the future.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/500
+ */
 declare function serverError(body?: object | string): Response;
 //#endregion
 //#region src/response/temporaryRedirect.d.ts
 /**
-* 307 Temporary Redirect
-*
-* The HTTP 307 Temporary Redirect redirection response status code indicates
-* that the resource requested has been temporarily moved to the URL in the
-* Location header.
-*
-* A browser receiving this status will automatically request the resource at
-* the URL in the Location header, redirecting the user to the new page. Search
-* engines receiving this response will not attribute links to the original URL
-* to the new resource, meaning no SEO value is transferred to the new URL.
-*
-* The method and the body of the original request are reused to perform the
-* redirected request. In the cases where you want the request method to be
-* changed to GET, use 303 See Other instead. This is useful when you want to
-* give an answer to a successful PUT request that is not the uploaded resource,
-* but a status monitor or confirmation message like "You have successfully
-* uploaded XYZ".
-*
-* The difference between 307 and 302 is that 307 guarantees that the client
-* will not change the request method and body when the redirected request is
-* made. With 302, older clients incorrectly changed the method to GET. 307 and
-* 302 responses are identical when the request method is GET.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/307
-*/
+ * 307 Temporary Redirect
+ *
+ * The HTTP 307 Temporary Redirect redirection response status code indicates
+ * that the resource requested has been temporarily moved to the URL in the
+ * Location header.
+ *
+ * A browser receiving this status will automatically request the resource at
+ * the URL in the Location header, redirecting the user to the new page. Search
+ * engines receiving this response will not attribute links to the original URL
+ * to the new resource, meaning no SEO value is transferred to the new URL.
+ *
+ * The method and the body of the original request are reused to perform the
+ * redirected request. In the cases where you want the request method to be
+ * changed to GET, use 303 See Other instead. This is useful when you want to
+ * give an answer to a successful PUT request that is not the uploaded resource,
+ * but a status monitor or confirmation message like "You have successfully
+ * uploaded XYZ".
+ *
+ * The difference between 307 and 302 is that 307 guarantees that the client
+ * will not change the request method and body when the redirected request is
+ * made. With 302, older clients incorrectly changed the method to GET. 307 and
+ * 302 responses are identical when the request method is GET.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/307
+ */
 declare function temporaryRedirect(location: string): Response;
 //#endregion
 //#region src/response/transfer.d.ts
 /**
-* Creates a redirect response with the supplied status code.
-*/
+ * Creates a redirect response with the supplied status code.
+ */
 declare function transfer(status: 300 | 301 | 302 | 303 | 304 | 307 | 308, location: string): Response;
 //#endregion
 //#region src/response/unauthorized.d.ts
 /**
-* 401 Unauthorized
-*
-* The HTTP 401 Unauthorized client error response status code indicates that a
-* request was not successful because it lacks valid authentication credentials
-* for the requested resource. This status code is sent with an HTTP
-* WWW-Authenticate response header that contains information on the
-* authentication scheme the server expects the client to include to make the
-* request successfully.
-*
-* A 401 Unauthorized is similar to the 403 Forbidden response, except that a
-* 403 is returned when a request contains valid credentials, but the client
-* does not have permissions to perform a certain action.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401
-*/
+ * 401 Unauthorized
+ *
+ * The HTTP 401 Unauthorized client error response status code indicates that a
+ * request was not successful because it lacks valid authentication credentials
+ * for the requested resource. This status code is sent with an HTTP
+ * WWW-Authenticate response header that contains information on the
+ * authentication scheme the server expects the client to include to make the
+ * request successfully.
+ *
+ * A 401 Unauthorized is similar to the 403 Forbidden response, except that a
+ * 403 is returned when a request contains valid credentials, but the client
+ * does not have permissions to perform a certain action.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401
+ */
 declare function unauthorized(body?: object | string): Response;
 //#endregion
 //#region src/response/unprocessable.d.ts
+type UnprocessableResponse<T extends object | string | undefined> = T extends object ? TypedResponse<Jsonify<T>> : Response;
 /**
-* 422 Unprocessable Content
-*
-* The HTTP 422 Unprocessable Content client error response status code
-* indicates that the server understood the content type of the request content,
-* and the syntax of the request content was correct, but it was unable to
-* process the contained instructions.
-*
-* Clients that receive a 422 response should expect that repeating the request
-* without modification will fail with the same error.
-*
-* See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/422
-*/
-declare function unprocessable(body?: object | string): Response;
+ * 422 Unprocessable Content
+ *
+ * The HTTP 422 Unprocessable Content client error response status code
+ * indicates that the server understood the content type of the request content,
+ * and the syntax of the request content was correct, but it was unable to
+ * process the contained instructions.
+ *
+ * Clients that receive a 422 response should expect that repeating the request
+ * without modification will fail with the same error.
+ *
+ * An object body is typed: it becomes the page's `$props.form` (with its JSON
+ * form) after a form submit, so validation errors can be surfaced with their
+ * field types via `PageForm`.
+ *
+ * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/422
+ */
+declare function unprocessable<T extends object | string | undefined>(body?: T): UnprocessableResponse<T>;
 //#endregion
-export { badRequest, created, forbidden, permRedirect as found, methodNotAllowed, permRedirect$1 as movedPermanently, notFound, notModified, ok, permanentRedirect, response, seeOther, serverError, temporaryRedirect, transfer, unauthorized, unprocessable };
+export { badRequest, created, forbidden, found, methodNotAllowed, movedPermanently, notFound, notModified, ok, permanentRedirect, response, seeOther, serverError, temporaryRedirect, transfer, unauthorized, unprocessable };
 //# sourceMappingURL=response.d.mts.map