@warlock.js/web 5.0.0

package/esm/server/buffered-response.mjs

@@ -0,0 +1,115 @@
+//#region ../web/src/server/buffered-response.ts
+/**
+* Runtime brand behind `LoaderShortCircuit` (web/src/context.ts:13-17
+* declares the compile-time half). A loader RETURNS this from
+* `response.redirect()` / `response.notFound()`; the settle stage detects it
+* by the symbol, never by shape.
+*/
+const LOADER_SHORT_CIRCUIT = Symbol("warlock.loader.shortCircuit");
+function isLoaderShortCircuit(value) {
+	return typeof value === "object" && value !== null && value[LOADER_SHORT_CIRCUIT] === true;
+}
+function shortCircuitSignal(init) {
+	return {
+		...init,
+		[LOADER_SHORT_CIRCUIT]: true
+	};
+}
+function createBufferedResponse() {
+	const buffer = {
+		headers: [],
+		cookies: []
+	};
+	const response = {
+		header(key, value) {
+			buffer.headers.push({
+				key,
+				value
+			});
+			return response;
+		},
+		cookie(name, value, options) {
+			buffer.cookies.push({
+				name,
+				value,
+				options
+			});
+			return response;
+		},
+		setStatusCode(statusCode) {
+			buffer.statusCode = statusCode;
+			return response;
+		},
+		/**
+		* A redirect is a status AND a `Location`; both belong in the buffer.
+		*
+		* Writing only `buffer.statusCode` here and carrying the URL out on the
+		* branded return value split one answer across two channels, and the
+		* emit only ever drained the first: the document path applied
+		* `bundle.commit.headers` and never read `bundle.shortCircuit`, so the
+		* browser got a bare `302` with an empty body and stayed put
+		* (design/loader-endpoint-seam-2026-08-23.md §5).
+		*
+		* Putting `Location` in the buffer fixes it once, at the declaration,
+		* for every consumer: the commit stage's live mirror
+		* (`execute-page-request.ts` commitBuffers — which mirrors headers and
+		* status only; its cookie half was removed so `Set-Cookie` is not
+		* appended twice, and `Location` rides the header half),
+		* `bundle.commit.headers`, `finishRender`'s header map, and the handler's
+		* `response.headers()` all carry it without any of them learning what a
+		* redirect is. The
+		* alternative — special-casing `shortCircuit.kind` at the emit — would
+		* have to be re-implemented by every emit path that ever exists, which
+		* is precisely how this shipped unnoticed the first time.
+		*
+		* The signal is still returned and still branded: the buffer says what
+		* the response should LOOK like, the signal says the pipeline must STOP.
+		* Those are different facts and both are still needed.
+		*/
+		redirect(url, statusCode = 302) {
+			buffer.statusCode = statusCode;
+			buffer.headers.push({
+				key: "Location",
+				value: url
+			});
+			return shortCircuitSignal({
+				kind: "redirect",
+				statusCode,
+				url
+			});
+		},
+		/** Same shape as `redirect`, at 301 — deliberately not special-cased. */
+		permanentRedirect(url) {
+			buffer.statusCode = 301;
+			buffer.headers.push({
+				key: "Location",
+				value: url
+			});
+			return shortCircuitSignal({
+				kind: "redirect",
+				statusCode: 301,
+				url
+			});
+		},
+		/**
+		* The other short-circuit kind. It shares the signal shape but has no
+		* URL, so it writes no `Location` — a 404 that redirects is not a thing.
+		*/
+		notFound(body) {
+			buffer.statusCode = 404;
+			return shortCircuitSignal({
+				kind: "notFound",
+				statusCode: 404,
+				body
+			});
+		}
+	};
+	return {
+		response,
+		buffer
+	};
+}
+
+//#endregion
+export { LOADER_SHORT_CIRCUIT, createBufferedResponse, isLoaderShortCircuit };
+//# sourceMappingURL=buffered-response.mjs.map

package/esm/server/buffered-response.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"buffered-response.mjs","names":[],"sources":["../../../../../../../web/src/server/buffered-response.ts"],"sourcesContent":["import type { LoaderShortCircuit, WebResponse } from \"../context\";\n\n/**\n * The per-loader response facade for pipeline stage 6.\n *\n * Loaders run in PARALLEL and never see the real `Response`: core's\n * `Response.header`/`cookie` write straight through to the fastify reply\n * (core/src/http/response.ts:919-923, :955-967), so three concurrent loaders\n * writing directly would interleave nondeterministically and a discarded\n * layer's writes could never be taken back. Instead each loader gets one of\n * these facades; every write lands in a buffer, and the pipeline's\n * settle/commit stage applies the surviving buffers to\n * the real response root→leaf, per cookie name / header key.\n */\n\nexport type BufferedHeader = {\n  key: string;\n  value: string;\n};\n\nexport type BufferedCookie = {\n  name: string;\n  value: unknown;\n  options?: Record<string, unknown>;\n};\n\nexport type ResponseBuffer = {\n  headers: BufferedHeader[];\n  cookies: BufferedCookie[];\n  statusCode?: number;\n};\n\n/**\n * Runtime brand behind `LoaderShortCircuit` (web/src/context.ts:13-17\n * declares the compile-time half). A loader RETURNS this from\n * `response.redirect()` / `response.notFound()`; the settle stage detects it\n * by the symbol, never by shape.\n */\nexport const LOADER_SHORT_CIRCUIT = Symbol(\"warlock.loader.shortCircuit\");\n\nexport type LoaderShortCircuitSignal = LoaderShortCircuit & {\n  kind: \"redirect\" | \"notFound\";\n  statusCode: number;\n  url?: string;\n  body?: unknown;\n};\n\nexport function isLoaderShortCircuit(value: unknown): value is LoaderShortCircuitSignal {\n  return (\n    typeof value === \"object\" &&\n    value !== null &&\n    (value as Record<PropertyKey, unknown>)[LOADER_SHORT_CIRCUIT] === true\n  );\n}\n\nfunction shortCircuitSignal(\n  init: Omit<LoaderShortCircuitSignal, keyof LoaderShortCircuit>,\n): LoaderShortCircuitSignal {\n  return { ...init, [LOADER_SHORT_CIRCUIT]: true } as unknown as LoaderShortCircuitSignal;\n}\n\n/**\n * The loader-facing surface is `WebResponse` (web/src/context.ts:73-88) plus\n * `cookie()`, which the commit contract needs so buffers can be applied\n * per cookie name.\n */\nexport type BufferedWebResponse = WebResponse & {\n  cookie(name: string, value: unknown, options?: Record<string, unknown>): BufferedWebResponse;\n};\n\nexport function createBufferedResponse(): {\n  response: BufferedWebResponse;\n  buffer: ResponseBuffer;\n} {\n  const buffer: ResponseBuffer = { headers: [], cookies: [] };\n\n  const response: BufferedWebResponse = {\n    header(key: string, value: string) {\n      buffer.headers.push({ key, value });\n      return response;\n    },\n\n    cookie(name: string, value: unknown, options?: Record<string, unknown>) {\n      buffer.cookies.push({ name, value, options });\n      return response;\n    },\n\n    setStatusCode(statusCode: number) {\n      buffer.statusCode = statusCode;\n      return response;\n    },\n\n    /**\n     * A redirect is a status AND a `Location`; both belong in the buffer.\n     *\n     * Writing only `buffer.statusCode` here and carrying the URL out on the\n     * branded return value split one answer across two channels, and the\n     * emit only ever drained the first: the document path applied\n     * `bundle.commit.headers` and never read `bundle.shortCircuit`, so the\n     * browser got a bare `302` with an empty body and stayed put\n     * (design/loader-endpoint-seam-2026-08-23.md §5).\n     *\n     * Putting `Location` in the buffer fixes it once, at the declaration,\n     * for every consumer: the commit stage's live mirror\n     * (`execute-page-request.ts` commitBuffers — which mirrors headers and\n     * status only; its cookie half was removed so `Set-Cookie` is not\n     * appended twice, and `Location` rides the header half),\n     * `bundle.commit.headers`, `finishRender`'s header map, and the handler's\n     * `response.headers()` all carry it without any of them learning what a\n     * redirect is. The\n     * alternative — special-casing `shortCircuit.kind` at the emit — would\n     * have to be re-implemented by every emit path that ever exists, which\n     * is precisely how this shipped unnoticed the first time.\n     *\n     * The signal is still returned and still branded: the buffer says what\n     * the response should LOOK like, the signal says the pipeline must STOP.\n     * Those are different facts and both are still needed.\n     */\n    redirect(url: string, statusCode = 302) {\n      buffer.statusCode = statusCode;\n      buffer.headers.push({ key: \"Location\", value: url });\n      return shortCircuitSignal({ kind: \"redirect\", statusCode, url });\n    },\n\n    /** Same shape as `redirect`, at 301 — deliberately not special-cased. */\n    permanentRedirect(url: string) {\n      buffer.statusCode = 301;\n      buffer.headers.push({ key: \"Location\", value: url });\n      return shortCircuitSignal({ kind: \"redirect\", statusCode: 301, url });\n    },\n\n    /**\n     * The other short-circuit kind. It shares the signal shape but has no\n     * URL, so it writes no `Location` — a 404 that redirects is not a thing.\n     */\n    notFound(body?: unknown) {\n      buffer.statusCode = 404;\n      return shortCircuitSignal({ kind: \"notFound\", statusCode: 404, body });\n    },\n  };\n\n  return { response, buffer };\n}\n"],"mappings":";;;;;;;AAsCA,MAAa,uBAAuB,OAAO,6BAA6B;AASxE,SAAgB,qBAAqB,OAAmD;CACtF,OACE,OAAO,UAAU,YACjB,UAAU,QACT,MAAuC,0BAA0B;AAEtE;AAEA,SAAS,mBACP,MAC0B;CAC1B,OAAO;EAAE,GAAG;GAAO,uBAAuB;CAAK;AACjD;AAWA,SAAgB,yBAGd;CACA,MAAM,SAAyB;EAAE,SAAS,CAAC;EAAG,SAAS,CAAC;CAAE;CAE1D,MAAM,WAAgC;EACpC,OAAO,KAAa,OAAe;GACjC,OAAO,QAAQ,KAAK;IAAE;IAAK;GAAM,CAAC;GAClC,OAAO;EACT;EAEA,OAAO,MAAc,OAAgB,SAAmC;GACtE,OAAO,QAAQ,KAAK;IAAE;IAAM;IAAO;GAAQ,CAAC;GAC5C,OAAO;EACT;EAEA,cAAc,YAAoB;GAChC,OAAO,aAAa;GACpB,OAAO;EACT;;;;;;;;;;;;;;;;;;;;;;;;;;;EA4BA,SAAS,KAAa,aAAa,KAAK;GACtC,OAAO,aAAa;GACpB,OAAO,QAAQ,KAAK;IAAE,KAAK;IAAY,OAAO;GAAI,CAAC;GACnD,OAAO,mBAAmB;IAAE,MAAM;IAAY;IAAY;GAAI,CAAC;EACjE;;EAGA,kBAAkB,KAAa;GAC7B,OAAO,aAAa;GACpB,OAAO,QAAQ,KAAK;IAAE,KAAK;IAAY,OAAO;GAAI,CAAC;GACnD,OAAO,mBAAmB;IAAE,MAAM;IAAY,YAAY;IAAK;GAAI,CAAC;EACtE;;;;;EAMA,SAAS,MAAgB;GACvB,OAAO,aAAa;GACpB,OAAO,mBAAmB;IAAE,MAAM;IAAY,YAAY;IAAK;GAAK,CAAC;EACvE;CACF;CAEA,OAAO;EAAE;EAAU;CAAO;AAC5B"}

package/esm/server/build-hydration-payload.mjs

@@ -0,0 +1,27 @@
+//#region ../web/src/server/build-hydration-payload.ts
+/**
+* Levels without a loader resolve to `undefined`, but the hydration contract
+* requires every data key to be PRESENT.
+*
+* An intentional `null` is preserved — a loader that returned `null` said
+* something, and flattening it would erase that. Only "no data at all" becomes
+* an empty object.
+*/
+function serializableData(data) {
+	return data === void 0 ? {} : data;
+}
+function buildHydrationPayload(bundle) {
+	return {
+		appData: serializableData(bundle.appData),
+		layoutData: serializableData(bundle.layoutData),
+		pageData: serializableData(bundle.pageData),
+		shared: serializableData(bundle.shared),
+		params: bundle.route.params,
+		...bundle.metadata === void 0 ? {} : { metadata: bundle.metadata },
+		name: bundle.route.name
+	};
+}
+
+//#endregion
+export { buildHydrationPayload };
+//# sourceMappingURL=build-hydration-payload.mjs.map

package/esm/server/build-hydration-payload.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"build-hydration-payload.mjs","names":[],"sources":["../../../../../../../web/src/server/build-hydration-payload.ts"],"sourcesContent":["/**\n * The ONE place the hydration payload's shape is decided.\n *\n * Two callers need the identical object and must never drift:\n *\n *   `render-page.ts`   embeds it in the document as `#__WARLOCK_DATA__`, which\n *                      is what a FULL page load hands the browser.\n *   the `_loader` route returns it as JSON, which is what a CLIENT navigation\n *                      fetches instead of re-rendering the document.\n *\n * Drift between those two is not a cosmetic bug: the browser builds the same\n * React tree from either source, so a key present on one path and absent on the\n * other produces a page that works when you land on it and breaks when you\n * navigate to it — or the reverse, which is worse, because the first visit is\n * the one everybody tests.\n *\n * Extracted rather than duplicated for exactly that reason. It was previously\n * assembled inline inside the renderer, where the loader route could not reach\n * it without copying five lines that would then be free to diverge.\n */\nimport type { HydrationDocumentPayloadSource } from \"../components/document-context\";\nimport type { PageDataBundle } from \"./execute-page-request\";\n\n/**\n * Levels without a loader resolve to `undefined`, but the hydration contract\n * requires every data key to be PRESENT.\n *\n * An intentional `null` is preserved — a loader that returned `null` said\n * something, and flattening it would erase that. Only \"no data at all\" becomes\n * an empty object.\n */\nfunction serializableData(data: unknown): unknown {\n  return data === undefined ? {} : data;\n}\n\nexport function buildHydrationPayload(bundle: PageDataBundle): HydrationDocumentPayloadSource {\n  return {\n    appData: serializableData(bundle.appData),\n    layoutData: serializableData(bundle.layoutData),\n    pageData: serializableData(bundle.pageData),\n    shared: serializableData(bundle.shared),\n    // The server's own match, carried for the same reason `name` is: the params\n    // are an ANSWER the router already gave, and re-deriving them in the\n    // browser from `location.pathname` would be a second matcher disagreeing\n    // with the server about the request it is hydrating. `{}` for a route with\n    // no dynamic segments — a real answer, not a missing one.\n    params: bundle.route.params,\n    // Spread, so \"the page produced no metadata\" is the SAME shape here and on\n    // the wire. `metadata: undefined` would be a key in the in-process object\n    // and no key at all after `JSON.stringify` — one type, two payload shapes,\n    // which is precisely the drift this file exists to prevent. Carried whole:\n    // `<Head/>` renders every member of `MetadataOutput`, so anything narrowed\n    // out here is a tag the first request has and a navigation does not.\n    ...(bundle.metadata === undefined ? {} : { metadata: bundle.metadata }),\n    // The matched entry's own name, carried untransformed from stage 1\n    // (`bundle.route.name` IS `matched.entry.name`, execute-page-request.ts).\n    // The browser reads it to look up the page the server resolved rather than\n    // re-matching the pathname — a second matcher can disagree with the server\n    // about the very request it is hydrating, and on a client navigation it\n    // would be disagreeing about a request the server already answered.\n    name: bundle.route.name,\n  };\n}\n"],"mappings":";;;;;;;;;AA+BA,SAAS,iBAAiB,MAAwB;CAChD,OAAO,SAAS,SAAY,CAAC,IAAI;AACnC;AAEA,SAAgB,sBAAsB,QAAwD;CAC5F,OAAO;EACL,SAAS,iBAAiB,OAAO,OAAO;EACxC,YAAY,iBAAiB,OAAO,UAAU;EAC9C,UAAU,iBAAiB,OAAO,QAAQ;EAC1C,QAAQ,iBAAiB,OAAO,MAAM;EAMtC,QAAQ,OAAO,MAAM;EAOrB,GAAI,OAAO,aAAa,SAAY,CAAC,IAAI,EAAE,UAAU,OAAO,SAAS;EAOrE,MAAM,OAAO,MAAM;CACrB;AACF"}

package/esm/server/client-asset-url-prefix.d.mts

@@ -0,0 +1,22 @@
+//#region ../web/src/server/client-asset-url-prefix.d.ts
+/**
+ * The SINGLE authority for where built client assets are served.
+ *
+ * Two halves must agree and only one of them may own the literal:
+ * `resolveHydrationClientUrl` GUARANTEES every URL it returns starts with this
+ * prefix, and the production static-file route MUST mount `<clientDir>/assets`
+ * at exactly this prefix by importing THIS symbol. A second `"/assets"`
+ * literal anywhere else is a drift bug: the two copies can be edited apart,
+ * and the failure mode is a silent 404 on the hydration script — the page
+ * renders, never hydrates, and nothing throws.
+ *
+ * WHY THE `assets` SUBDIRECTORY AND NOT THE CLIENT ROOT: the client build dir
+ * also contains `.vite/manifest.json`, the build→runtime handoff artifact,
+ * which must NEVER be publicly served. Mounting the client root would expose
+ * it. Mounting only the `assets` subdirectory keeps the manifest unreachable
+ * while still serving every hashed artifact the manifest points at.
+ */
+declare const CLIENT_ASSET_URL_PREFIX = "/assets";
+//#endregion
+export { CLIENT_ASSET_URL_PREFIX };
+//# sourceMappingURL=client-asset-url-prefix.d.mts.map

package/esm/server/client-asset-url-prefix.mjs

@@ -0,0 +1,23 @@
+//#region ../web/src/server/client-asset-url-prefix.ts
+/**
+* The SINGLE authority for where built client assets are served.
+*
+* Two halves must agree and only one of them may own the literal:
+* `resolveHydrationClientUrl` GUARANTEES every URL it returns starts with this
+* prefix, and the production static-file route MUST mount `<clientDir>/assets`
+* at exactly this prefix by importing THIS symbol. A second `"/assets"`
+* literal anywhere else is a drift bug: the two copies can be edited apart,
+* and the failure mode is a silent 404 on the hydration script — the page
+* renders, never hydrates, and nothing throws.
+*
+* WHY THE `assets` SUBDIRECTORY AND NOT THE CLIENT ROOT: the client build dir
+* also contains `.vite/manifest.json`, the build→runtime handoff artifact,
+* which must NEVER be publicly served. Mounting the client root would expose
+* it. Mounting only the `assets` subdirectory keeps the manifest unreachable
+* while still serving every hashed artifact the manifest points at.
+*/
+const CLIENT_ASSET_URL_PREFIX = "/assets";
+
+//#endregion
+export { CLIENT_ASSET_URL_PREFIX };
+//# sourceMappingURL=client-asset-url-prefix.mjs.map

package/esm/server/client-asset-url-prefix.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"client-asset-url-prefix.mjs","names":[],"sources":["../../../../../../../web/src/server/client-asset-url-prefix.ts"],"sourcesContent":["/**\n * The SINGLE authority for where built client assets are served.\n *\n * Two halves must agree and only one of them may own the literal:\n * `resolveHydrationClientUrl` GUARANTEES every URL it returns starts with this\n * prefix, and the production static-file route MUST mount `<clientDir>/assets`\n * at exactly this prefix by importing THIS symbol. A second `\"/assets\"`\n * literal anywhere else is a drift bug: the two copies can be edited apart,\n * and the failure mode is a silent 404 on the hydration script — the page\n * renders, never hydrates, and nothing throws.\n *\n * WHY THE `assets` SUBDIRECTORY AND NOT THE CLIENT ROOT: the client build dir\n * also contains `.vite/manifest.json`, the build→runtime handoff artifact,\n * which must NEVER be publicly served. Mounting the client root would expose\n * it. Mounting only the `assets` subdirectory keeps the manifest unreachable\n * while still serving every hashed artifact the manifest points at.\n */\nexport const CLIENT_ASSET_URL_PREFIX = \"/assets\";\n"],"mappings":";;;;;;;;;;;;;;;;;;AAiBA,MAAa,0BAA0B"}

package/esm/server/create-page-module-loader.mjs

@@ -0,0 +1,49 @@
+//#region ../web/src/server/create-page-module-loader.ts
+/**
+* Asked for a module this build does not contain.
+*
+* Hard failure, deliberately. Every alternative — returning `undefined`, an
+* empty namespace, or falling back to a dynamic import — turns a build that
+* shipped the wrong module table into a page that renders blank, or into a
+* production process reaching for source files that are not deployed. The id
+* is in the message because the whole diagnosis is "which id, and why is it
+* not in the table"; the count is there because zero entries means the build
+* discovered no pages at all, which is a different fault from a mismatch.
+*/
+var PageModuleNotInManifestError = class extends Error {
+	constructor(moduleId, knownIdCount) {
+		super(`Cannot serve a page module: "${moduleId}" is not in this build's page manifest (${knownIdCount} module(s) available). Module ids are the manifest's \`sourceFile\` values — app-root-relative POSIX paths, extension included — and must match exactly. Re-run \`warlock build\` so the generated \`pages.ts\` barrel matches what is being served.`);
+		this.name = "PageModuleNotInManifestError";
+	}
+};
+/**
+* Build the loader for ONE manifest.
+*
+* Ids are compared by exact string equality against the `sourceFile` each
+* entry carries — no lowercasing, no separator swapping, no extension
+* stripping. Both sides of that comparison come from the same generator
+* (`generatePagesBarrel` writes every `sourceFile` through one
+* app-root-relative POSIX derivation), so any spelling difference is a real
+* disagreement about which file is meant, and a normalizer would only hide it.
+*
+* A layout shared by several pages appears once per chain it belongs to; the
+* generator emits one identifier per layout file, so every occurrence of an id
+* carries the same namespace object and re-registering it is a no-op.
+*/
+function createPageModuleLoader(manifest) {
+	const modulesById = /* @__PURE__ */ new Map();
+	if (manifest.app) modulesById.set(manifest.app.sourceFile, manifest.app.module);
+	for (const page of manifest.pages) {
+		modulesById.set(page.sourceFile, page.module);
+		for (const layout of page.layouts) modulesById.set(layout.sourceFile, layout.module);
+	}
+	return async (moduleId) => {
+		const module = modulesById.get(moduleId);
+		if (module === void 0) throw new PageModuleNotInManifestError(moduleId, modulesById.size);
+		return module;
+	};
+}
+
+//#endregion
+export { PageModuleNotInManifestError, createPageModuleLoader };
+//# sourceMappingURL=create-page-module-loader.mjs.map

package/esm/server/create-page-module-loader.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"create-page-module-loader.mjs","names":[],"sources":["../../../../../../../web/src/server/create-page-module-loader.ts"],"sourcesContent":["/**\n * The production answer to \"how do I load a page module\".\n *\n * `createPageRouteHandler` takes loading a module as an INPUT\n * ({@link PageModuleLoader}) precisely so the two runtimes can answer it\n * differently. Dev hands it `moduleId => vite.ssrLoadModule(moduleId)`;\n * production has no Vite and nothing to evaluate — the generated `pages.ts`\n * barrel already imported every page, layout and the app root statically, and\n * {@link PageManifest} is the table those namespace objects arrived in. So the\n * production loader does not load anything: it is a LOOKUP over modules that\n * are already in memory, and this file is that lookup and nothing else.\n */\nimport type { PageModuleLoader } from \"./create-page-route-handler\";\nimport type { PageManifest } from \"./page-manifest\";\n\n/**\n * Asked for a module this build does not contain.\n *\n * Hard failure, deliberately. Every alternative — returning `undefined`, an\n * empty namespace, or falling back to a dynamic import — turns a build that\n * shipped the wrong module table into a page that renders blank, or into a\n * production process reaching for source files that are not deployed. The id\n * is in the message because the whole diagnosis is \"which id, and why is it\n * not in the table\"; the count is there because zero entries means the build\n * discovered no pages at all, which is a different fault from a mismatch.\n */\nexport class PageModuleNotInManifestError extends Error {\n  public constructor(moduleId: string, knownIdCount: number) {\n    super(\n      `Cannot serve a page module: \"${moduleId}\" is not in this build's page manifest ` +\n        `(${knownIdCount} module(s) available). Module ids are the manifest's \\`sourceFile\\` ` +\n        \"values — app-root-relative POSIX paths, extension included — and must match exactly. \" +\n        \"Re-run `warlock build` so the generated `pages.ts` barrel matches what is being served.\",\n    );\n    this.name = \"PageModuleNotInManifestError\";\n  }\n}\n\n/**\n * Build the loader for ONE manifest.\n *\n * Ids are compared by exact string equality against the `sourceFile` each\n * entry carries — no lowercasing, no separator swapping, no extension\n * stripping. Both sides of that comparison come from the same generator\n * (`generatePagesBarrel` writes every `sourceFile` through one\n * app-root-relative POSIX derivation), so any spelling difference is a real\n * disagreement about which file is meant, and a normalizer would only hide it.\n *\n * A layout shared by several pages appears once per chain it belongs to; the\n * generator emits one identifier per layout file, so every occurrence of an id\n * carries the same namespace object and re-registering it is a no-op.\n */\nexport function createPageModuleLoader(manifest: PageManifest): PageModuleLoader {\n  const modulesById = new Map<string, Record<string, unknown>>();\n\n  if (manifest.app) {\n    modulesById.set(manifest.app.sourceFile, manifest.app.module);\n  }\n\n  for (const page of manifest.pages) {\n    modulesById.set(page.sourceFile, page.module);\n\n    for (const layout of page.layouts) {\n      modulesById.set(layout.sourceFile, layout.module);\n    }\n  }\n\n  // `async` so an unknown id surfaces as a rejection rather than a synchronous\n  // throw: the handler awaits every module through one `Promise.all`, and a\n  // loader that fails both ways depending on the reason is a loader callers\n  // have to guard twice.\n  return async (moduleId: string) => {\n    const module = modulesById.get(moduleId);\n\n    if (module === undefined) {\n      throw new PageModuleNotInManifestError(moduleId, modulesById.size);\n    }\n\n    return module;\n  };\n}\n"],"mappings":";;;;;;;;;;;;AA0BA,IAAa,+BAAb,cAAkD,MAAM;CACtD,AAAO,YAAY,UAAkB,cAAsB;EACzD,MACE,gCAAgC,SAAS,0CACnC,aAAa,qPAGrB;EACA,KAAK,OAAO;CACd;AACF;;;;;;;;;;;;;;;AAgBA,SAAgB,uBAAuB,UAA0C;CAC/E,MAAM,8BAAc,IAAI,IAAqC;CAE7D,IAAI,SAAS,KACX,YAAY,IAAI,SAAS,IAAI,YAAY,SAAS,IAAI,MAAM;CAG9D,KAAK,MAAM,QAAQ,SAAS,OAAO;EACjC,YAAY,IAAI,KAAK,YAAY,KAAK,MAAM;EAE5C,KAAK,MAAM,UAAU,KAAK,SACxB,YAAY,IAAI,OAAO,YAAY,OAAO,MAAM;CAEpD;CAMA,OAAO,OAAO,aAAqB;EACjC,MAAM,SAAS,YAAY,IAAI,QAAQ;EAEvC,IAAI,WAAW,QACb,MAAM,IAAI,6BAA6B,UAAU,YAAY,IAAI;EAGnE,OAAO;CACT;AACF"}

package/esm/server/create-page-route-handler.mjs

@@ -0,0 +1,107 @@
+import { DATA_RESPONSE_CONTENT_TYPE, WARLOCK_DATA_REQUEST_HEADER, isDataRequest } from "../routing/data-request.mjs";
+import { buildHydrationPayload } from "./build-hydration-payload.mjs";
+import { renderPageRequest } from "./render-page.mjs";
+
+//#region ../web/src/server/create-page-route-handler.ts
+function escapeHtmlAttribute(value) {
+	return value.replace(/[&<>"']/g, (character) => {
+		switch (character) {
+			case "&": return "&amp;";
+			case "<": return "&lt;";
+			case ">": return "&gt;";
+			case "\"": return "&quot;";
+			default: return "&#39;";
+		}
+	});
+}
+function installHydrationClientModule(html, moduleUrl, nonce) {
+	if (moduleUrl === void 0 || html === "") return html;
+	const closingBodyIndex = html.lastIndexOf("</body>");
+	if (closingBodyIndex === -1) throw new Error("installPageRoutes: cannot install the hydration client module because the rendered document has no closing </body> tag.");
+	const script = `<script type="module"${nonce === void 0 ? "" : ` nonce="${escapeHtmlAttribute(nonce)}"`} src="${escapeHtmlAttribute(moduleUrl)}"><\/script>`;
+	return `${html.slice(0, closingBodyIndex)}${script}${html.slice(closingBodyIndex)}`;
+}
+/**
+* Put the page's stylesheets in `<head>`, so the first paint is styled.
+*
+* Without this the document carries no CSS at all. The stylesheet reaches the
+* browser only because the CLIENT bundle imports it, which means it is applied
+* by JavaScript after the module graph loads — the page renders unstyled first
+* and restyles a moment later. Correct markup, wrong-looking page, and nothing
+* in the console to explain it.
+*
+* A `<link>` in `<head>` is render-blocking, which is exactly what is wanted
+* here: the browser holds the first paint until the CSS is in, so there is no
+* flash rather than a faster ugly one.
+*
+* Inserted before `</head>` rather than after `<head>` so an application's own
+* `<link>`/`<style>` in the root document still comes FIRST and can be
+* overridden by these — matching how the framework's tags are documented to
+* behave, and keeping cascade order predictable.
+*/
+function installStylesheets(html, stylesheetUrls) {
+	if (stylesheetUrls.length === 0 || html === "") return html;
+	const closingHeadIndex = html.lastIndexOf("</head>");
+	if (closingHeadIndex === -1) return html;
+	const links = stylesheetUrls.map((url) => `<link rel="stylesheet" href="${escapeHtmlAttribute(url)}">`).join("");
+	return `${html.slice(0, closingHeadIndex)}${links}${html.slice(closingHeadIndex)}`;
+}
+/**
+* Build the handler for ONE page route. Per request it loads the App + layout
+* + page triple (concurrently, in that order), renders the URL through
+* `renderPageRequest`, splices in the hydration module, applies the committed
+* cookies and headers, and flushes the document.
+*
+* No try/catch, deliberately: loader/render throws are already absorbed by the
+* pipeline's boundary machinery inside `renderPageRequest`, and anything that
+* escapes (a module-load failure, the missing-`</body>` throw above) belongs to
+* the router's error path — which is exactly where it went before.
+*/
+function createPageRouteHandler(options) {
+	const { path, name, appFile, pageFile, layoutFile, loadModule, hydrationClientModuleUrl, stylesheetUrls, applyBufferedCookie } = options;
+	return async ({ request, response }) => {
+		const [appModule, layoutModule, ownPageModule] = await Promise.all([
+			loadModule(appFile),
+			layoutFile ? loadModule(layoutFile) : Promise.resolve({}),
+			loadModule(pageFile)
+		]);
+		const routes = [{
+			path,
+			name,
+			triple: {
+				app: appModule,
+				layout: layoutModule,
+				page: ownPageModule
+			}
+		}];
+		const wantsData = isDataRequest(request.header(WARLOCK_DATA_REQUEST_HEADER, void 0));
+		const rendered = await renderPageRequest(request.path, {
+			routes,
+			createHttp: () => ({
+				request,
+				response
+			})
+		});
+		if (wantsData) {
+			for (const cookie of rendered.cookies) applyBufferedCookie(response, cookie);
+			response.headers(rendered.headers);
+			response.header("Vary", WARLOCK_DATA_REQUEST_HEADER);
+			if (rendered.bundle === void 0) {
+				response.setContentType(DATA_RESPONSE_CONTENT_TYPE);
+				await response.send(JSON.stringify({ error: "not_found" }), rendered.status);
+				return;
+			}
+			response.setContentType(DATA_RESPONSE_CONTENT_TYPE);
+			await response.send(JSON.stringify(buildHydrationPayload(rendered.bundle)), rendered.status);
+			return;
+		}
+		const html = installHydrationClientModule(installStylesheets(rendered.html, stylesheetUrls ?? []), hydrationClientModuleUrl, hydrationClientModuleUrl === void 0 ? void 0 : request.nonce);
+		for (const cookie of rendered.cookies) applyBufferedCookie(response, cookie);
+		response.headers(rendered.headers);
+		await response.html(html, rendered.status);
+	};
+}
+
+//#endregion
+export { createPageRouteHandler };
+//# sourceMappingURL=create-page-route-handler.mjs.map

package/esm/server/create-page-route-handler.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"create-page-route-handler.mjs","names":[],"sources":["../../../../../../../web/src/server/create-page-route-handler.ts"],"sourcesContent":["/**\r\n * The page handler, as a named seam.\r\n *\r\n * This is the request handler `installPageRoutes` used to inline into its\r\n * `router.get(...)` call (`install-page-routes.ts:236-275` before this\r\n * extraction; the pre-extraction copy is `scratchpad/install-page-routes.ts.orig`).\r\n * The behaviour is unchanged, byte for byte — what changes is that it is now\r\n * a named, exported, independently constructible function instead of a closure\r\n * over eight ambient bindings of `installPageRoutes`.\r\n *\r\n * WHY IT TAKES `loadModule` AND NOT A `ViteDevServer`: loading a module is the\r\n * only capability the handler ever needed, and the two runtimes answer it\r\n * differently — dev goes through Vite's SSR graph\r\n * (`vite.ssrLoadModule`, `install-page-routes.ts:207`), production reads the\r\n * already-built page manifest (`page-manifest.ts`). Taking \"how to load a\r\n * module\" as an INPUT is what lets the same handler serve both, and what lets\r\n * a test construct it with a plain async function — no Vite, no dev server, no\r\n * `app/` directory on disk.\r\n *\r\n * Scope: this file creates a seam and nothing else. It does not implement\r\n * `type: \"page\"` routing, HTML error pages, or any other new capability.\r\n */\r\nimport type { HttpContext, Response } from \"@warlock.js/core\";\r\n\r\nimport {\r\n  DATA_RESPONSE_CONTENT_TYPE,\r\n  isDataRequest,\r\n  WARLOCK_DATA_REQUEST_HEADER,\r\n} from \"../routing/data-request\";\r\nimport { buildHydrationPayload } from \"./build-hydration-payload\";\r\nimport type { BufferedCookie } from \"./buffered-response\";\r\nimport type { PageRouteEntry, PageTripleModule } from \"./execute-page-request\";\r\nimport { renderPageRequest } from \"./render-page\";\r\n\r\n/**\r\n * How the handler obtains a page/layout/app module, by the same id\r\n * (`appFile`/`layoutFile`/`pageFile`) the caller registered it under. In dev\r\n * this is `moduleId => vite.ssrLoadModule(moduleId)`; the connector already\r\n * owns the dev/prod split, so the handler never learns which one it got.\r\n */\r\nexport type PageModuleLoader = (moduleId: string) => Promise<unknown>;\r\n\r\nexport type PageRouteHandlerOptions = {\r\n  /** The composed, registered route path — `composeRoutePath`'s output. */\r\n  path: string;\r\n  /** The resolved route name; shared namespace with API routes. */\r\n  name: string;\r\n  /** The single global app-root file, e.g. `<appSrcRoot>/web/root.tsx`. */\r\n  appFile: string;\r\n  /** The page module's id. */\r\n  pageFile: string;\r\n  /** The page's own-directory `layout.tsx`, when it has one. */\r\n  layoutFile?: string | undefined;\r\n  loadModule: PageModuleLoader;\r\n  /** Browser module appended after the server-rendered document. */\r\n  hydrationClientModuleUrl?: string;\r\n  /**\r\n   * Stylesheet URLs for this page, emitted into `<head>` so the FIRST paint is\r\n   * styled. Absent or empty means the application has no CSS — it never means\r\n   * a stylesheet failed to resolve, which is the build's job to report.\r\n   */\r\n  stylesheetUrls?: readonly string[];\r\n  /** Same helper `dev-server.ts` exports — passed in, never imported. */\r\n  applyBufferedCookie: (response: Response, cookie: BufferedCookie) => void;\r\n};\r\n\r\nexport type PageRouteHandler = (context: HttpContext) => Promise<void>;\r\n\r\nfunction escapeHtmlAttribute(value: string): string {\r\n  return value.replace(/[&<>\"']/g, (character) => {\r\n    switch (character) {\r\n      case \"&\":\r\n        return \"&amp;\";\r\n      case \"<\":\r\n        return \"&lt;\";\r\n      case \">\":\r\n        return \"&gt;\";\r\n      case '\"':\r\n        return \"&quot;\";\r\n      default:\r\n        return \"&#39;\";\r\n    }\r\n  });\r\n}\r\n\r\nfunction installHydrationClientModule(\r\n  html: string,\r\n  moduleUrl: string | undefined,\r\n  nonce: string | undefined,\r\n): string {\r\n  if (moduleUrl === undefined || html === \"\") return html;\r\n\r\n  const closingBodyIndex = html.lastIndexOf(\"</body>\");\r\n  if (closingBodyIndex === -1) {\r\n    throw new Error(\r\n      \"installPageRoutes: cannot install the hydration client module because the rendered document has no closing </body> tag.\",\r\n    );\r\n  }\r\n\r\n  const nonceAttribute = nonce === undefined ? \"\" : ` nonce=\"${escapeHtmlAttribute(nonce)}\"`;\r\n  const script = `<script type=\"module\"${nonceAttribute} src=\"${escapeHtmlAttribute(moduleUrl)}\"></script>`;\r\n  return `${html.slice(0, closingBodyIndex)}${script}${html.slice(closingBodyIndex)}`;\r\n}\r\n\r\n/**\r\n * Put the page's stylesheets in `<head>`, so the first paint is styled.\r\n *\r\n * Without this the document carries no CSS at all. The stylesheet reaches the\r\n * browser only because the CLIENT bundle imports it, which means it is applied\r\n * by JavaScript after the module graph loads — the page renders unstyled first\r\n * and restyles a moment later. Correct markup, wrong-looking page, and nothing\r\n * in the console to explain it.\r\n *\r\n * A `<link>` in `<head>` is render-blocking, which is exactly what is wanted\r\n * here: the browser holds the first paint until the CSS is in, so there is no\r\n * flash rather than a faster ugly one.\r\n *\r\n * Inserted before `</head>` rather than after `<head>` so an application's own\r\n * `<link>`/`<style>` in the root document still comes FIRST and can be\r\n * overridden by these — matching how the framework's tags are documented to\r\n * behave, and keeping cascade order predictable.\r\n */\r\nfunction installStylesheets(html: string, stylesheetUrls: readonly string[]): string {\r\n  if (stylesheetUrls.length === 0 || html === \"\") return html;\r\n\r\n  const closingHeadIndex = html.lastIndexOf(\"</head>\");\r\n\r\n  // No `<head>` is not an error the way a missing `</body>` is: a root that\r\n  // renders no head is unusual but legal, and losing the stylesheet is a\r\n  // cosmetic failure where losing hydration is a broken page. Silently\r\n  // dropping it would be the wrong trade the other way, though — so the\r\n  // document is left exactly as rendered and the caller's own missing-`</body>`\r\n  // check remains the loud one.\r\n  if (closingHeadIndex === -1) return html;\r\n\r\n  const links = stylesheetUrls\r\n    .map((url) => `<link rel=\"stylesheet\" href=\"${escapeHtmlAttribute(url)}\">`)\r\n    .join(\"\");\r\n\r\n  return `${html.slice(0, closingHeadIndex)}${links}${html.slice(closingHeadIndex)}`;\r\n}\r\n\r\n/**\r\n * Build the handler for ONE page route. Per request it loads the App + layout\r\n * + page triple (concurrently, in that order), renders the URL through\r\n * `renderPageRequest`, splices in the hydration module, applies the committed\r\n * cookies and headers, and flushes the document.\r\n *\r\n * No try/catch, deliberately: loader/render throws are already absorbed by the\r\n * pipeline's boundary machinery inside `renderPageRequest`, and anything that\r\n * escapes (a module-load failure, the missing-`</body>` throw above) belongs to\r\n * the router's error path — which is exactly where it went before.\r\n */\r\nexport function createPageRouteHandler(options: PageRouteHandlerOptions): PageRouteHandler {\r\n  const {\r\n    path,\r\n    name,\r\n    appFile,\r\n    pageFile,\r\n    layoutFile,\r\n    loadModule,\r\n    hydrationClientModuleUrl,\r\n    stylesheetUrls,\r\n    applyBufferedCookie,\r\n  } = options;\r\n\r\n  return async ({ request, response }: HttpContext) => {\r\n    const [appModule, layoutModule, ownPageModule] = await Promise.all([\r\n      loadModule(appFile),\r\n      layoutFile ? loadModule(layoutFile) : Promise.resolve({}),\r\n      loadModule(pageFile),\r\n    ]);\r\n\r\n    const triple: PageRouteEntry[\"triple\"] = {\r\n      app: appModule as PageTripleModule,\r\n      layout: layoutModule as PageTripleModule,\r\n      page: ownPageModule as PageTripleModule,\r\n    };\r\n\r\n    const routes: PageRouteEntry[] = [{ path, name, triple }];\r\n\r\n    // A DATA request runs everything above and below this line identically —\r\n    // it is the same route, the same match and the same pipeline — and differs\r\n    // only in what gets written at the end. Decided here, before the render, so\r\n    // the branch is visibly about REPRESENTATION and not about behaviour.\r\n    const wantsData = isDataRequest(request.header(WARLOCK_DATA_REQUEST_HEADER, undefined));\r\n\r\n    const rendered = await renderPageRequest(request.path, {\r\n      routes,\r\n      createHttp: () => ({ request, response }),\r\n    });\r\n\r\n    if (wantsData) {\r\n      // Cookies and headers FIRST, exactly as the document path does below and\r\n      // for the same reason: a client navigation must be able to log a user in,\r\n      // set a flash cookie or be redirected, and dropping those on this path\r\n      // would make a navigation behave differently from a page load of the same\r\n      // URL — the one difference this branch is not allowed to introduce.\r\n      for (const cookie of rendered.cookies) {\r\n        applyBufferedCookie(response, cookie);\r\n      }\r\n\r\n      response.headers(rendered.headers);\r\n\r\n      // So a shared cache can never serve a document to a client that asked for\r\n      // JSON, or the reverse. See `data-request.ts` on why this stays even\r\n      // while page responses are `no-store`.\r\n      response.header(\"Vary\", WARLOCK_DATA_REQUEST_HEADER);\r\n\r\n      // `bundle` is absent on exactly one path: nothing matched, so no pipeline\r\n      // ran and there is no payload to build. Fastify already matched this\r\n      // route to get here, so reaching it means `request.path` did not satisfy\r\n      // the entry's own pattern — answered as the 404 it is, rather than\r\n      // synthesising an empty payload the client would try to render as a page.\r\n      if (rendered.bundle === undefined) {\r\n        response.setContentType(DATA_RESPONSE_CONTENT_TYPE);\r\n        await response.send(JSON.stringify({ error: \"not_found\" }), rendered.status);\r\n\r\n        return;\r\n      }\r\n\r\n      // SERIALIZED HERE, and handed over as a STRING on purpose.\r\n      //\r\n      // `response.send(object)` runs the body through core's `Response.parse`,\r\n      // which recurses the object, calls `toJSON()` on anything that has one\r\n      // (assigning `request` onto it as it goes) and rebuilds arrays. That is\r\n      // the right behaviour for a controller returning Resources; it is the\r\n      // wrong behaviour here, because the DOCUMENT path serializes this exact\r\n      // object with a plain `JSON.stringify` into `#__WARLOCK_DATA__`. Routing\r\n      // one path through a transformer and not the other is precisely the\r\n      // drift `build-hydration-payload.ts` exists to prevent — the browser\r\n      // would build one tree on a page load and a different one on a\r\n      // navigation to the same URL.\r\n      //\r\n      // A string body also bypasses `parseBody()` entirely, so the content type\r\n      // has to be declared rather than inferred from an object body.\r\n      response.setContentType(DATA_RESPONSE_CONTENT_TYPE);\r\n      await response.send(JSON.stringify(buildHydrationPayload(rendered.bundle)), rendered.status);\r\n\r\n      return;\r\n    }\r\n\r\n    // Stylesheets first: they go in `<head>`, the hydration module goes before\r\n    // `</body>`, and doing the head work on the already-rendered string keeps\r\n    // both splices in one place rather than threading CSS through the React\r\n    // render just to reach the same bytes.\r\n    const styled = installStylesheets(rendered.html, stylesheetUrls ?? []);\r\n\r\n    const html = installHydrationClientModule(\r\n      styled,\r\n      hydrationClientModuleUrl,\r\n      hydrationClientModuleUrl === undefined ? undefined : request.nonce,\r\n    );\r\n\r\n    // THE single site that puts a committed cookie on the wire. The commit\r\n    // stage used to mirror the same list onto the live response as well\r\n    // (`commitBuffers`, execute-page-request.ts), and because fastify's\r\n    // `setCookie` APPENDS rather than sets, every page response carried two\r\n    // identical `Set-Cookie` headers — happy path included. The mirror's\r\n    // cookie half is gone; this loop is what remains, and it is the right\r\n    // one: it runs at stage 10a, after the render, alongside the headers and\r\n    // the final status, so it applies the answer the pipeline actually\r\n    // settled on rather than the one it had at stage 7.\r\n    for (const cookie of rendered.cookies) {\r\n      applyBufferedCookie(response, cookie);\r\n    }\r\n\r\n    response.headers(rendered.headers);\r\n\r\n    await response.html(html, rendered.status);\r\n  };\r\n}\r\n"],"mappings":";;;;;AAoEA,SAAS,oBAAoB,OAAuB;CAClD,OAAO,MAAM,QAAQ,aAAa,cAAc;EAC9C,QAAQ,WAAR;GACE,KAAK,KACH,OAAO;GACT,KAAK,KACH,OAAO;GACT,KAAK,KACH,OAAO;GACT,KAAK,MACH,OAAO;GACT,SACE,OAAO;EACX;CACF,CAAC;AACH;AAEA,SAAS,6BACP,MACA,WACA,OACQ;CACR,IAAI,cAAc,UAAa,SAAS,IAAI,OAAO;CAEnD,MAAM,mBAAmB,KAAK,YAAY,SAAS;CACnD,IAAI,qBAAqB,IACvB,MAAM,IAAI,MACR,yHACF;CAIF,MAAM,SAAS,wBADQ,UAAU,SAAY,KAAK,WAAW,oBAAoB,KAAK,EAAE,GAClC,QAAQ,oBAAoB,SAAS,EAAE;CAC7F,OAAO,GAAG,KAAK,MAAM,GAAG,gBAAgB,IAAI,SAAS,KAAK,MAAM,gBAAgB;AAClF;;;;;;;;;;;;;;;;;;;AAoBA,SAAS,mBAAmB,MAAc,gBAA2C;CACnF,IAAI,eAAe,WAAW,KAAK,SAAS,IAAI,OAAO;CAEvD,MAAM,mBAAmB,KAAK,YAAY,SAAS;CAQnD,IAAI,qBAAqB,IAAI,OAAO;CAEpC,MAAM,QAAQ,eACX,KAAK,QAAQ,gCAAgC,oBAAoB,GAAG,EAAE,GAAG,CAAC,CAC1E,KAAK,EAAE;CAEV,OAAO,GAAG,KAAK,MAAM,GAAG,gBAAgB,IAAI,QAAQ,KAAK,MAAM,gBAAgB;AACjF;;;;;;;;;;;;AAaA,SAAgB,uBAAuB,SAAoD;CACzF,MAAM,EACJ,MACA,MACA,SACA,UACA,YACA,YACA,0BACA,gBACA,wBACE;CAEJ,OAAO,OAAO,EAAE,SAAS,eAA4B;EACnD,MAAM,CAAC,WAAW,cAAc,iBAAiB,MAAM,QAAQ,IAAI;GACjE,WAAW,OAAO;GAClB,aAAa,WAAW,UAAU,IAAI,QAAQ,QAAQ,CAAC,CAAC;GACxD,WAAW,QAAQ;EACrB,CAAC;EAQD,MAAM,SAA2B,CAAC;GAAE;GAAM;GAAM;IAL9C,KAAK;IACL,QAAQ;IACR,MAAM;GAG6C;EAAE,CAAC;EAMxD,MAAM,YAAY,cAAc,QAAQ,OAAO,6BAA6B,MAAS,CAAC;EAEtF,MAAM,WAAW,MAAM,kBAAkB,QAAQ,MAAM;GACrD;GACA,mBAAmB;IAAE;IAAS;GAAS;EACzC,CAAC;EAED,IAAI,WAAW;GAMb,KAAK,MAAM,UAAU,SAAS,SAC5B,oBAAoB,UAAU,MAAM;GAGtC,SAAS,QAAQ,SAAS,OAAO;GAKjC,SAAS,OAAO,QAAQ,2BAA2B;GAOnD,IAAI,SAAS,WAAW,QAAW;IACjC,SAAS,eAAe,0BAA0B;IAClD,MAAM,SAAS,KAAK,KAAK,UAAU,EAAE,OAAO,YAAY,CAAC,GAAG,SAAS,MAAM;IAE3E;GACF;GAiBA,SAAS,eAAe,0BAA0B;GAClD,MAAM,SAAS,KAAK,KAAK,UAAU,sBAAsB,SAAS,MAAM,CAAC,GAAG,SAAS,MAAM;GAE3F;EACF;EAQA,MAAM,OAAO,6BAFE,mBAAmB,SAAS,MAAM,kBAAkB,CAAC,CAG7D,GACL,0BACA,6BAA6B,SAAY,SAAY,QAAQ,KAC/D;EAWA,KAAK,MAAM,UAAU,SAAS,SAC5B,oBAAoB,UAAU,MAAM;EAGtC,SAAS,QAAQ,SAAS,OAAO;EAEjC,MAAM,SAAS,KAAK,MAAM,SAAS,MAAM;CAC3C;AACF"}

package/esm/server/dev-server.mjs

@@ -0,0 +1,167 @@
+import { stripVTControlCharacters } from "node:util";
+
+//#region ../web/src/server/dev-server.ts
+/**
+* Replay a buffered cookie onto the response that will actually be sent.
+*
+* `BufferedCookie.options` is a loosely-typed bag (`Record<string, unknown>`)
+* because the buffer is written by loader code before any response exists; the
+* cast hands it to `Response.cookie()`, which is where the option shape is
+* defined and enforced for every other caller in the framework.
+*/
+function applyBufferedCookie(response, cookie) {
+	response.cookie(cookie.name, cookie.value, cookie.options ?? {});
+}
+/**
+* Where a captured transform/resolve failure rides from Vite's connect stack to
+* the Fastify hook that mounted it.
+*
+* A `Symbol.for` key on the raw `IncomingMessage` rather than a `WeakMap`
+* because the two halves live in different modules and are wired at different
+* times; the request object is the only thing they provably share, and the
+* symbol cannot collide with a Vite/Fastify/user property.
+*
+* Exported so a test can stage a captured failure without booting a vite
+* server, and so the two halves cannot drift onto two different keys.
+*/
+const DEV_TRANSFORM_ERROR_BODY = Symbol.for("warlock.web.devTransformErrorBody");
+/**
+* The status a refused module now answers with.
+*
+* NOT the 404 this replaces. That 404 was never a decision about the module —
+* it is what an unmatched URL gets once vite has declined it, and which of the
+* two framework answers you see depends only on whether the app declares a
+* catch-all page: with one (v5/app does — `path: "*"`) the request lands in the
+* page pipeline, matches no route, and `./render-page.ts:604` returns
+* `{ html: "", status: 404 }` for `./create-page-route-handler.ts:147` to write
+* as an empty `text/html` body; without one it is `core/src/router/router.ts:879`.
+* Either way "the module does not exist" is precisely the wrong thing to tell a
+* developer whose module exists and was refused. 500 is the status VITE ITSELF writes for
+* this exact condition when it is not in middleware mode
+* (`node_modules/vite/dist/node/chunks/config.js:9528`), so this adopts that
+* convention rather than inventing a third one.
+*/
+const DEV_TRANSFORM_ERROR_STATUS = 500;
+/**
+* The dev error transport was constructed while the process is hosting a
+* PRODUCTION build. Refused by name at construction rather than degraded,
+* because everything this transport does — file paths, source frames, plugin
+* names — is exactly what a production response must never carry.
+*/
+var DevErrorTransportInProductionError = class extends Error {
+	constructor() {
+		super("The dev error transport was constructed with `Application.runtimeStrategy === \"production\"`. It exists only to put a Vite transform failure in front of a developer and its response body carries absolute file paths and source frames, so it must never be mounted on a production-hosted server.");
+		this.name = "DevErrorTransportInProductionError";
+	}
+};
+/**
+* Render a refused module's failure as the plain-text body the browser gets.
+*
+* Formatting is DELEGATED to vite's own exported `buildErrorMessage`, not
+* reimplemented: it is the same function vite uses to print the failure to the
+* terminal, so the text a developer reads in the network panel and the text
+* they read in the terminal cannot drift. Two things are added around it —
+* `error.name`, which vite's terminal path replaces with a fixed
+* "Internal server error:" prefix and which is the single most useful token for
+* a named gate refusal (`ProjectionAmbiguityError`), and the `cause` chain,
+* which vite does not walk.
+*
+* `stripVTControlCharacters` is not optional: `buildErrorMessage` colours its
+* output with picocolors, which is ON whenever the dev server owns a TTY, and
+* raw ANSI escapes in an HTTP body are noise. Vite strips them the same way for
+* the overlay payload (`config.js:9490-9497`).
+*
+* The stack is deliberately omitted (`includeStack: false`). A gate refusal's
+* stack points into the gate, not into the developer's code; the fields that
+* locate the problem — plugin, file, line, source frame — are what
+* `buildErrorMessage` puts there without it.
+*/
+function formatDevTransformError(error, buildErrorMessage) {
+	const failure = error instanceof Error ? error : new Error(typeof error === "string" ? error : String(error));
+	const lines = [stripVTControlCharacters(buildErrorMessage(failure, [`${failure.name}: ${failure.message}`], false))];
+	let cause = failure.cause;
+	while (cause instanceof Error) {
+		lines.push(`  Caused by: ${cause.name}: ${stripVTControlCharacters(cause.message)}`);
+		cause = cause.cause;
+	}
+	return `${lines.join("\n")}\n`;
+}
+/**
+* DEV-ONLY. Capture the transform/resolve failure that vite is about to throw
+* away, so the request that caused it can answer with it.
+*
+* WHY THIS IS A PLUGIN AND NOT A `middlewares.use(...)` CALL — this is the
+* whole defect, and it is an ordering fact, not a style choice:
+*
+*  - Vite mounts its own error handler LAST, built as
+*    `errorMiddleware(server, !!middlewareMode)`
+*    (`node_modules/vite/dist/node/chunks/config.js:25705`).
+*  - In middleware mode that `allowNext` flag is `true`, and the handler then
+*    logs the error to the TERMINAL and calls `next()` — with no error
+*    (`config.js:9525-9527`).
+*  - connect only routes an error to a 4-arity handler while an error is in
+*    flight (`config.js:10611-10626`), so `next()` clears it: every layer after
+*    that point, INCLUDING the `done` callback `./web-connector.ts` hands the
+*    stack, is called as if the request had simply gone unhandled. The
+*    framework then answers the only way it can for a URL it does not know — a
+*    404, empty (see {@link DEV_TRANSFORM_ERROR_STATUS} for which of the two
+*    produces it).
+*  - Anything registered with `vite.middlewares.use(...)` after `createServer()`
+*    resolves lands AFTER that handler and is therefore unreachable. A
+*    `configureServer` POST hook does not: vite runs post hooks at
+*    `config.js:25700`, five lines BEFORE it mounts its error handler.
+*
+* So this sits between the failure and vite's logger. It captures, then calls
+* `next(error)` and lets vite's own handler run exactly as before — the
+* terminal message and the `hot.send({ type: "error" })` overlay push
+* (`config.js:9511-9521`) are unchanged. This transport ADDS a reader; it
+* replaces nothing.
+*
+* @param isProductionRuntime the connector's own hosting-mode signal
+*        (`./web-connector.ts:122`) — passed in rather than re-derived so there
+*        is one definition of "this process is Vite-hosted", not two.
+*/
+function devErrorTransportPlugin(options) {
+	const { isProductionRuntime, buildErrorMessage } = options;
+	if (isProductionRuntime()) throw new DevErrorTransportInProductionError();
+	const capture = (error, request, _response, next) => {
+		if (isProductionRuntime()) return next(error);
+		request[DEV_TRANSFORM_ERROR_BODY] = formatDevTransformError(error, buildErrorMessage);
+		next(error);
+	};
+	return {
+		name: "warlock:dev-error-transport",
+		apply: "serve",
+		configureServer(server) {
+			return () => {
+				server.middlewares.use(capture);
+			};
+		}
+	};
+}
+/**
+* Answer the request with the failure {@link devErrorTransportPlugin} captured,
+* if there was one. Returns `false` when there was not, which is the normal
+* case and means "carry on down the framework's own path".
+*
+* Called from the Fastify `onRequest` hook that mounts vite
+* (`./web-connector.ts:321`), in the `done` callback — i.e. at the one moment
+* where connect has finished, vite has declined to answer, and the framework is
+* about to 404. Writing to the raw `ServerResponse` rather than through Fastify
+* is what the mount already does for every response vite serves, so this stays
+* on the same side of the seam.
+*/
+function sendCapturedDevError(request, response) {
+	const body = request[DEV_TRANSFORM_ERROR_BODY];
+	if (typeof body !== "string") return false;
+	if (response.headersSent || response.writableEnded) return false;
+	response.statusCode = 500;
+	response.setHeader("content-type", "text/plain; charset=utf-8");
+	response.setHeader("cache-control", "no-store");
+	response.end(body);
+	return true;
+}
+
+//#endregion
+export { applyBufferedCookie, devErrorTransportPlugin, sendCapturedDevError };
+//# sourceMappingURL=dev-server.mjs.map

package/esm/server/dev-server.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"dev-server.mjs","names":[],"sources":["../../../../../../../web/src/server/dev-server.ts"],"sourcesContent":["/**\n * Two small pieces of the dev/SSR page plumbing that `./web-connector.ts` wires\n * but deliberately does not own: the buffered-cookie commit, and the DEV-ONLY\n * error transport that stops a refused module from reaching the browser as a\n * bare 404 (see {@link devErrorTransportPlugin}).\n *\n * ---\n *\n * Commits one buffered cookie (`BufferedCookie`, from `./buffered-response.ts`)\n * onto the live Warlock `Response` — the single place in the SSR page pipeline\n * where a cookie the loader buffered turns into a real `Set-Cookie` header.\n *\n * It delegates to core's `Response.cookie()` rather than talking to fastify.\n * That method already owns everything this file used to reimplement: it takes\n * core's own `CookieOptions`, JSON-stringifies the value unless `{ raw: true }`,\n * strips the core-only `raw` flag, and layers the framework's secure-cookie\n * defaults and the `http.cookies.options` config under the per-call options.\n * Going through it means the SSR page path and every ordinary controller emit\n * cookies by the exact same code, so the two cannot drift apart.\n *\n * The helper is passed INTO `installPageRoutes`/`createPageRouteHandler` as an\n * option rather than imported by them, which is what keeps this module out of a\n * cycle with the page-route installer.\n */\nimport type { IncomingMessage, ServerResponse } from \"node:http\";\nimport { stripVTControlCharacters } from \"node:util\";\nimport type { Connect, Plugin } from \"vite\";\nimport type { Response } from \"@warlock.js/core\";\nimport type { BufferedCookie } from \"./buffered-response\";\n\n/**\n * Replay a buffered cookie onto the response that will actually be sent.\n *\n * `BufferedCookie.options` is a loosely-typed bag (`Record<string, unknown>`)\n * because the buffer is written by loader code before any response exists; the\n * cast hands it to `Response.cookie()`, which is where the option shape is\n * defined and enforced for every other caller in the framework.\n */\nexport function applyBufferedCookie(response: Response, cookie: BufferedCookie): void {\n  response.cookie(cookie.name, cookie.value as never, (cookie.options ?? {}) as never);\n}\n\n/**\n * Where a captured transform/resolve failure rides from Vite's connect stack to\n * the Fastify hook that mounted it.\n *\n * A `Symbol.for` key on the raw `IncomingMessage` rather than a `WeakMap`\n * because the two halves live in different modules and are wired at different\n * times; the request object is the only thing they provably share, and the\n * symbol cannot collide with a Vite/Fastify/user property.\n *\n * Exported so a test can stage a captured failure without booting a vite\n * server, and so the two halves cannot drift onto two different keys.\n */\nexport const DEV_TRANSFORM_ERROR_BODY = Symbol.for(\"warlock.web.devTransformErrorBody\");\n\ntype DevTransformErrorCarrier = { [DEV_TRANSFORM_ERROR_BODY]?: string };\n\n/**\n * The status a refused module now answers with.\n *\n * NOT the 404 this replaces. That 404 was never a decision about the module —\n * it is what an unmatched URL gets once vite has declined it, and which of the\n * two framework answers you see depends only on whether the app declares a\n * catch-all page: with one (v5/app does — `path: \"*\"`) the request lands in the\n * page pipeline, matches no route, and `./render-page.ts:604` returns\n * `{ html: \"\", status: 404 }` for `./create-page-route-handler.ts:147` to write\n * as an empty `text/html` body; without one it is `core/src/router/router.ts:879`.\n * Either way \"the module does not exist\" is precisely the wrong thing to tell a\n * developer whose module exists and was refused. 500 is the status VITE ITSELF writes for\n * this exact condition when it is not in middleware mode\n * (`node_modules/vite/dist/node/chunks/config.js:9528`), so this adopts that\n * convention rather than inventing a third one.\n */\nexport const DEV_TRANSFORM_ERROR_STATUS = 500;\n\n/**\n * `buildErrorMessage` as vite exports it. Declared structurally so this module\n * needs no value import of vite — vite is an optional, dev-only peer and a\n * production install does not carry it.\n */\nexport type BuildErrorMessage = (\n  error: Error,\n  args?: string[],\n  includeStack?: boolean,\n) => string;\n\n/**\n * The dev error transport was constructed while the process is hosting a\n * PRODUCTION build. Refused by name at construction rather than degraded,\n * because everything this transport does — file paths, source frames, plugin\n * names — is exactly what a production response must never carry.\n */\nexport class DevErrorTransportInProductionError extends Error {\n  public constructor() {\n    super(\n      \"The dev error transport was constructed with `Application.runtimeStrategy === \" +\n        '\"production\"`. It exists only to put a Vite transform failure in front of a ' +\n        \"developer and its response body carries absolute file paths and source frames, \" +\n        \"so it must never be mounted on a production-hosted server.\",\n    );\n    this.name = \"DevErrorTransportInProductionError\";\n  }\n}\n\n/**\n * Render a refused module's failure as the plain-text body the browser gets.\n *\n * Formatting is DELEGATED to vite's own exported `buildErrorMessage`, not\n * reimplemented: it is the same function vite uses to print the failure to the\n * terminal, so the text a developer reads in the network panel and the text\n * they read in the terminal cannot drift. Two things are added around it —\n * `error.name`, which vite's terminal path replaces with a fixed\n * \"Internal server error:\" prefix and which is the single most useful token for\n * a named gate refusal (`ProjectionAmbiguityError`), and the `cause` chain,\n * which vite does not walk.\n *\n * `stripVTControlCharacters` is not optional: `buildErrorMessage` colours its\n * output with picocolors, which is ON whenever the dev server owns a TTY, and\n * raw ANSI escapes in an HTTP body are noise. Vite strips them the same way for\n * the overlay payload (`config.js:9490-9497`).\n *\n * The stack is deliberately omitted (`includeStack: false`). A gate refusal's\n * stack points into the gate, not into the developer's code; the fields that\n * locate the problem — plugin, file, line, source frame — are what\n * `buildErrorMessage` puts there without it.\n */\nexport function formatDevTransformError(\n  error: unknown,\n  buildErrorMessage: BuildErrorMessage,\n): string {\n  const failure =\n    error instanceof Error ? error : new Error(typeof error === \"string\" ? error : String(error));\n\n  const lines = [\n    stripVTControlCharacters(\n      buildErrorMessage(failure, [`${failure.name}: ${failure.message}`], false),\n    ),\n  ];\n\n  // Walk the `cause` chain. A gate may wrap a parser failure, and the wrapped\n  // message is usually the one naming the actual syntax that was refused.\n  let cause = (failure as { cause?: unknown }).cause;\n\n  while (cause instanceof Error) {\n    lines.push(`  Caused by: ${cause.name}: ${stripVTControlCharacters(cause.message)}`);\n    cause = (cause as { cause?: unknown }).cause;\n  }\n\n  return `${lines.join(\"\\n\")}\\n`;\n}\n\n/**\n * DEV-ONLY. Capture the transform/resolve failure that vite is about to throw\n * away, so the request that caused it can answer with it.\n *\n * WHY THIS IS A PLUGIN AND NOT A `middlewares.use(...)` CALL — this is the\n * whole defect, and it is an ordering fact, not a style choice:\n *\n *  - Vite mounts its own error handler LAST, built as\n *    `errorMiddleware(server, !!middlewareMode)`\n *    (`node_modules/vite/dist/node/chunks/config.js:25705`).\n *  - In middleware mode that `allowNext` flag is `true`, and the handler then\n *    logs the error to the TERMINAL and calls `next()` — with no error\n *    (`config.js:9525-9527`).\n *  - connect only routes an error to a 4-arity handler while an error is in\n *    flight (`config.js:10611-10626`), so `next()` clears it: every layer after\n *    that point, INCLUDING the `done` callback `./web-connector.ts` hands the\n *    stack, is called as if the request had simply gone unhandled. The\n *    framework then answers the only way it can for a URL it does not know — a\n *    404, empty (see {@link DEV_TRANSFORM_ERROR_STATUS} for which of the two\n *    produces it).\n *  - Anything registered with `vite.middlewares.use(...)` after `createServer()`\n *    resolves lands AFTER that handler and is therefore unreachable. A\n *    `configureServer` POST hook does not: vite runs post hooks at\n *    `config.js:25700`, five lines BEFORE it mounts its error handler.\n *\n * So this sits between the failure and vite's logger. It captures, then calls\n * `next(error)` and lets vite's own handler run exactly as before — the\n * terminal message and the `hot.send({ type: \"error\" })` overlay push\n * (`config.js:9511-9521`) are unchanged. This transport ADDS a reader; it\n * replaces nothing.\n *\n * @param isProductionRuntime the connector's own hosting-mode signal\n *        (`./web-connector.ts:122`) — passed in rather than re-derived so there\n *        is one definition of \"this process is Vite-hosted\", not two.\n */\nexport function devErrorTransportPlugin(options: {\n  isProductionRuntime: () => boolean;\n  buildErrorMessage: BuildErrorMessage;\n}): Plugin {\n  const { isProductionRuntime, buildErrorMessage } = options;\n\n  if (isProductionRuntime()) {\n    throw new DevErrorTransportInProductionError();\n  }\n\n  const capture: Connect.ErrorHandleFunction = (error, request, _response, next) => {\n    // Re-asserted per request, not just at construction: `runtimeStrategy` is\n    // process state and a transport that leaks source frames is not something\n    // to hold open on a boot-time reading alone. In production this layer is a\n    // pass-through and vite's handler behaves exactly as it does today.\n    if (isProductionRuntime()) return next(error);\n\n    (request as DevTransformErrorCarrier)[DEV_TRANSFORM_ERROR_BODY] = formatDevTransformError(\n      error,\n      buildErrorMessage,\n    );\n\n    next(error);\n  };\n\n  return {\n    name: \"warlock:dev-error-transport\",\n    // Belt to the `isProductionRuntime` braces: this plugin has no business in\n    // a `vite build` graph either.\n    apply: \"serve\",\n    configureServer(server) {\n      // RETURNING a function is what makes this a POST hook — the ordering the\n      // note above depends on. Mounting inline here would land the layer BEFORE\n      // vite's transform middleware, where no error has been thrown yet.\n      return () => {\n        server.middlewares.use(capture);\n      };\n    },\n  };\n}\n\n/**\n * Answer the request with the failure {@link devErrorTransportPlugin} captured,\n * if there was one. Returns `false` when there was not, which is the normal\n * case and means \"carry on down the framework's own path\".\n *\n * Called from the Fastify `onRequest` hook that mounts vite\n * (`./web-connector.ts:321`), in the `done` callback — i.e. at the one moment\n * where connect has finished, vite has declined to answer, and the framework is\n * about to 404. Writing to the raw `ServerResponse` rather than through Fastify\n * is what the mount already does for every response vite serves, so this stays\n * on the same side of the seam.\n */\nexport function sendCapturedDevError(request: IncomingMessage, response: ServerResponse): boolean {\n  const body = (request as DevTransformErrorCarrier)[DEV_TRANSFORM_ERROR_BODY];\n\n  if (typeof body !== \"string\") return false;\n\n  // A middleware further down may have answered already (vite serves plenty of\n  // requests itself). Never write twice; the captured body is then just dropped.\n  if (response.headersSent || response.writableEnded) return false;\n\n  response.statusCode = DEV_TRANSFORM_ERROR_STATUS;\n  response.setHeader(\"content-type\", \"text/plain; charset=utf-8\");\n  // A refusal is a fact about the CURRENT source. Caching it would survive the\n  // edit that fixes it.\n  response.setHeader(\"cache-control\", \"no-store\");\n  response.end(body);\n\n  return true;\n}\n"],"mappings":";;;;;;;;;;;AAsCA,SAAgB,oBAAoB,UAAoB,QAA8B;CACpF,SAAS,OAAO,OAAO,MAAM,OAAO,OAAiB,OAAO,WAAW,CAAC,CAAW;AACrF;;;;;;;;;;;;;AAcA,MAAa,2BAA2B,OAAO,IAAI,mCAAmC;;;;;;;;;;;;;;;;;AAoBtF,MAAa,6BAA6B;;;;;;;AAmB1C,IAAa,qCAAb,cAAwD,MAAM;CAC5D,AAAO,cAAc;EACnB,MACE,uSAIF;EACA,KAAK,OAAO;CACd;AACF;;;;;;;;;;;;;;;;;;;;;;;AAwBA,SAAgB,wBACd,OACA,mBACQ;CACR,MAAM,UACJ,iBAAiB,QAAQ,QAAQ,IAAI,MAAM,OAAO,UAAU,WAAW,QAAQ,OAAO,KAAK,CAAC;CAE9F,MAAM,QAAQ,CACZ,yBACE,kBAAkB,SAAS,CAAC,GAAG,QAAQ,KAAK,IAAI,QAAQ,SAAS,GAAG,KAAK,CAC3E,CACF;CAIA,IAAI,QAAS,QAAgC;CAE7C,OAAO,iBAAiB,OAAO;EAC7B,MAAM,KAAK,gBAAgB,MAAM,KAAK,IAAI,yBAAyB,MAAM,OAAO,GAAG;EACnF,QAAS,MAA8B;CACzC;CAEA,OAAO,GAAG,MAAM,KAAK,IAAI,EAAE;AAC7B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAqCA,SAAgB,wBAAwB,SAG7B;CACT,MAAM,EAAE,qBAAqB,sBAAsB;CAEnD,IAAI,oBAAoB,GACtB,MAAM,IAAI,mCAAmC;CAG/C,MAAM,WAAwC,OAAO,SAAS,WAAW,SAAS;EAKhF,IAAI,oBAAoB,GAAG,OAAO,KAAK,KAAK;EAE5C,AAAC,QAAqC,4BAA4B,wBAChE,OACA,iBACF;EAEA,KAAK,KAAK;CACZ;CAEA,OAAO;EACL,MAAM;EAGN,OAAO;EACP,gBAAgB,QAAQ;GAItB,aAAa;IACX,OAAO,YAAY,IAAI,OAAO;GAChC;EACF;CACF;AACF;;;;;;;;;;;;;AAcA,SAAgB,qBAAqB,SAA0B,UAAmC;CAChG,MAAM,OAAQ,QAAqC;CAEnD,IAAI,OAAO,SAAS,UAAU,OAAO;CAIrC,IAAI,SAAS,eAAe,SAAS,eAAe,OAAO;CAE3D,SAAS;CACT,SAAS,UAAU,gBAAgB,2BAA2B;CAG9D,SAAS,UAAU,iBAAiB,UAAU;CAC9C,SAAS,IAAI,IAAI;CAEjB,OAAO;AACT"}

package/esm/server/execute-page-request.d.mts

@@ -0,0 +1 @@
+export { };