@torpor/build 0.4.10 → 0.4.12

package/src/response/found.ts

@@ -0,0 +1,30 @@
+import transfer from "./transfer";
+
+/**
+ * 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
+ */
+export default function permRedirect(location: string): Response {
+	return transfer(308, location);
+}

package/src/response/methodNotAllowed.ts

@@ -0,0 +1,18 @@
+import response from "./response";
+
+/**
+ * 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
+ */
+export default function methodNotAllowed(body?: object | string): Response {
+	return response(405, body ?? "Method not allowed");
+}

package/src/response/movedPermanently.ts

@@ -0,0 +1,25 @@
+import transfer from "./transfer";
+
+/**
+ * 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
+ */
+export default function permRedirect(location: string): Response {
+	return transfer(308, location);
+}

package/src/response/notFound.ts

@@ -0,0 +1,24 @@
+import response from "./response";
+
+/**
+ * 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
+ */
+export default function notFound(body?: object | string): Response {
+	return response(404, body ?? "Not found");
+}

package/src/response/notModified.ts

@@ -0,0 +1,34 @@
+import transfer from "./transfer";
+
+/**
+ * 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
+ */
+export default function notModified(location: string): Response {
+	return transfer(304, location);
+}

package/src/response/ok.ts

@@ -0,0 +1,29 @@
+import response from "./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
+ */
+export default function ok(body?: object | string): Response {
+	return response(200, body);
+}

package/src/response/permanentRedirect.ts

@@ -0,0 +1,30 @@
+import transfer from "./transfer";
+
+/**
+ * 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
+ */
+export default function permanentRedirect(location: string): Response {
+	return transfer(308, location);
+}

package/src/response/response.ts

@@ -0,0 +1,22 @@
+/**
+ * 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".
+ */
+export default function response(status: number, body?: object | string): Response {
+	let headers: Record<string, string> | undefined = undefined;
+	if (body) {
+		if (typeof body === "object") {
+			headers = { "content-type": "application/json" };
+			body = JSON.stringify(body);
+		} else {
+			headers = { "content-type": "text/plain" };
+		}
+	}
+	return new Response(body, {
+		status,
+		headers,
+	});
+}

package/src/response/seeOther.ts

@@ -0,0 +1,19 @@
+import transfer from "./transfer";
+
+/**
+ * 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
+ */
+export default function seeOther(location: string): Response {
+	return transfer(303, location);
+}

package/src/response/serverError.ts

@@ -0,0 +1,24 @@
+import response from "./response";
+
+/**
+ * 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
+ */
+export default function serverError(body?: object | string): Response {
+	return response(500, body ?? "Server error");
+}

package/src/response/temporaryRedirect.ts

@@ -0,0 +1,31 @@
+import transfer from "./transfer";
+
+/**
+ * 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
+ */
+export default function temporaryRedirect(location: string): Response {
+	return transfer(307, location);
+}

package/src/response/transfer.ts

@@ -0,0 +1,14 @@
+/**
+ * Creates a redirect response with the supplied status code.
+ */
+export default function transfer(
+	status: 300 | 301 | 302 | 303 | 304 | 307 | 308,
+	location: string,
+): Response {
+	return new Response(null, {
+		status,
+		headers: {
+			location,
+		},
+	});
+}

package/src/response/unauthorized.ts

@@ -0,0 +1,21 @@
+import response from "./response";
+
+/**
+ * 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
+ */
+export default function unauthorized(body?: object | string): Response {
+	return response(401, body ?? "Unauthorized");
+}

package/src/response/unprocessable.ts

@@ -0,0 +1,18 @@
+import response from "./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
+ */
+export default function unprocessable(body?: object | string): Response {
+	return response(422, body ?? "Unprocessable");
+}

package/src/response.ts

@@ -0,0 +1,37 @@
+import badRequest from "./response/badRequest";
+import created from "./response/created";
+import forbidden from "./response/forbidden";
+import found from "./response/found";
+import methodNotAllowed from "./response/methodNotAllowed";
+import movedPermanently from "./response/movedPermanently";
+import notFound from "./response/notFound";
+import notModified from "./response/notModified";
+import ok from "./response/ok";
+import permanentRedirect from "./response/permanentRedirect";
+import response from "./response/response";
+import seeOther from "./response/seeOther";
+import serverError from "./response/serverError";
+import temporaryRedirect from "./response/temporaryRedirect";
+import transfer from "./response/transfer";
+import unauthorized from "./response/unauthorized";
+import unprocessable from "./response/unprocessable";
+
+export {
+	response,
+	ok,
+	created,
+	transfer,
+	movedPermanently,
+	found,
+	seeOther,
+	notModified,
+	temporaryRedirect,
+	permanentRedirect,
+	badRequest,
+	unauthorized,
+	forbidden,
+	notFound,
+	methodNotAllowed,
+	unprocessable,
+	serverError,
+};

package/src/run/prepareTemplate.ts

@@ -0,0 +1,39 @@
+export default function prepareTemplate(
+	template: string,
+	clientScript: string,
+	clientDevScript?: string,
+): string {
+	let result = template;
+
+	// Put %COMPONENT_HEAD% before </head>
+	// This is where styles will go
+	let headStart = result.indexOf("</head>");
+	if (headStart === -1) {
+		throw new Error(`Couldn't find <head> end tag`);
+	}
+	result = result.substring(0, headStart) + "%COMPONENT_HEAD%" + result.substring(headStart);
+
+	// Put %COMPONENT_BODY% inside <div id="app"></div>
+	// This is where the component's HTML will go
+	let bodyStart = regexIndexOf(result, /<div\s+id=("app"|'app'|app)\s+/);
+	bodyStart = result.indexOf(">", bodyStart) + 1;
+	let bodyEnd = result.indexOf("</div>", bodyStart);
+	if (bodyStart === -1 || bodyEnd === -1) {
+		throw new Error(`Couldn't find <div id="app"></div>`);
+	}
+	result = result.substring(0, bodyStart) + "%COMPONENT_BODY%" + result.substring(bodyEnd);
+
+	// Add the clientEntry script at the very end, for hydrating and navigating
+	if (clientDevScript) {
+		result += `<script type="module" src="${clientDevScript}"></script>`;
+	}
+	result += `<script type="module" src="${clientScript}"></script>`;
+
+	return result;
+}
+
+// From https://stackoverflow.com/a/274094
+function regexIndexOf(string: string, regex: RegExp, position?: number) {
+	var indexOf = string.substring(position || 0).search(regex);
+	return indexOf >= 0 ? indexOf + (position || 0) : indexOf;
+}

package/src/run/run.ts

@@ -0,0 +1,62 @@
+import fs from "node:fs";
+import path from "node:path";
+import { transformWithEsbuild } from "vite";
+import Site from "../site/Site";
+import runBuild from "./runBuild";
+import runDev from "./runDev";
+import runPreview from "./runPreview";
+
+export default async function run(
+	folder: string,
+	mode: "dev" | "build" | "preview",
+): Promise<void> {
+	// Look for and load a site.config.js/ts file in the working directory
+	let configFile = "";
+	let deleteConfigFile = false;
+	const jsConfigFile = path.join(folder, "site.config.js");
+	const tsConfigFile = path.join(folder, "site.config.ts");
+	if (fs.existsSync(jsConfigFile)) {
+		// If it's JS, we can just import it straight up
+		configFile = jsConfigFile;
+	} else if (fs.existsSync(tsConfigFile)) {
+		// If it's TS, we need to convert it to JS
+		// TODO: Put the generated file somewhere better (dist?)
+		configFile = path.join(folder, "site.config.temp.js");
+		let source = fs.readFileSync(tsConfigFile, "utf-8");
+		let transformed = await transformWithEsbuild(source, tsConfigFile, {
+			loader: "ts",
+		});
+		fs.writeFileSync(configFile, transformed.code);
+		deleteConfigFile = true;
+	} else {
+		throw new Error("site.config file not found");
+	}
+
+	const site = (await import(configFile)).default as Site;
+	if (!site || !site.root || !site.routes) {
+		throw new Error("Invalid site in config file");
+	}
+	if (deleteConfigFile) {
+		fs.rmSync(configFile);
+	}
+
+	switch (mode) {
+		case "dev": {
+			await runDev(site);
+			break;
+		}
+		case "build": {
+			await runBuild(site);
+			break;
+		}
+		case "preview": {
+			await runPreview(site);
+			break;
+		}
+		default: {
+			console.log("No mode passed, running in dev");
+			await runDev(site);
+			break;
+		}
+	}
+}

package/src/run/runBuild.ts

@@ -0,0 +1,77 @@
+import torpor from "@torpor/unplugin/vite";
+import { existsSync, promises as fs } from "node:fs";
+import path from "node:path";
+import { build, defineConfig } from "vite";
+import Site from "../site/Site";
+import manifest from "../site/manifest.ts";
+
+// TODO: Don't cache index.html in dev?
+// TODO: Multiple hook.server locations
+// TODO: Don't reload layouts during client routing
+// TODO: Call the correct +page and +server routes when in the same folder
+
+export default async function runBuild(site: Site): Promise<void> {
+	// Delete the dist folder if it exists
+	const distFolder = path.resolve(site.root, "dist");
+	if (existsSync(distFolder)) {
+		await fs.rm(distFolder, { recursive: true });
+	}
+	const clientFolder = path.join(distFolder, "client");
+	const serverFolder = path.join(distFolder, "server");
+
+	// HOOK: Prebuild
+	if (site.adapter.prebuild) {
+		await site.adapter.prebuild(site);
+	}
+
+	// TODO: From a setting
+	let siteHtml = path.resolve(site.root, "src/site.html");
+
+	const siteFolder = path.resolve(site.root, "./node_modules/@torpor/build/src/site/");
+	let clientScript = path.join(siteFolder, "clientEntry.ts");
+	let serverScript = path.join(siteFolder, "serverEntry.ts");
+
+	// Build the client assets, including site.html and the route files
+	// EXCLUDING anything with `server.js` in the name
+	const clientConfig = structuredClone(site.viteConfig ?? {});
+	clientConfig.plugins = [manifest(site), torpor(), ...site.plugins];
+	clientConfig.build ??= {};
+	clientConfig.build.outDir = clientFolder;
+	clientConfig.build.rollupOptions ??= {};
+	clientConfig.build.rollupOptions.input = [
+		siteHtml,
+		clientScript,
+		...site.routes
+			.filter((r) => !/server\.(ts|js)$/.test(r.file))
+			.map((r) => path.resolve(site.root, r.file)),
+		...site.inputs.filter((f) => !/server\.(ts|js)$/.test(f)),
+	];
+	clientConfig.build.ssrManifest = true;
+	await build(defineConfig(clientConfig));
+
+	// Build the server assets, including the server entry script and the route
+	// files
+	const serverConfig = structuredClone(site.viteConfig ?? {});
+	serverConfig.plugins = [manifest(site, true), torpor(), ...site.plugins];
+	serverConfig.build ??= {};
+	serverConfig.build.outDir = serverFolder;
+	serverConfig.build.rollupOptions ??= {};
+	serverConfig.build.rollupOptions.input = [
+		serverScript,
+		...site.routes.map((r) => path.resolve(site.root, r.file)),
+		...site.inputs,
+	];
+	serverConfig.build.ssr = serverScript;
+	await build(defineConfig(serverConfig));
+
+	// Move the site.html file into /client
+	// HACK: Should do this in Rollup if possible?
+	siteHtml = path.join(clientFolder, "site.html");
+	await fs.rename(path.join(clientFolder, "src", "site.html"), siteHtml);
+	await fs.rm(path.join(clientFolder, "src"), { recursive: true });
+
+	// HOOK: Postbuild
+	if (site.adapter.postbuild) {
+		await site.adapter.postbuild(site);
+	}
+}

package/src/run/runDev.ts

@@ -0,0 +1,89 @@
+import estorpor from "@torpor/unplugin/esbuild";
+import torpor from "@torpor/unplugin/vite";
+import { configDotenv } from "dotenv";
+import { promises as fs } from "node:fs";
+import path from "node:path";
+import { createServer as createViteServer } from "vite";
+import { serverError } from "../response.ts";
+import Server from "../server/Server.ts";
+import connectMiddleware from "../server/connect/connectMiddleware.ts";
+import Site from "../site/Site.ts";
+import manifest from "../site/manifest.ts";
+import prepareTemplate from "./prepareTemplate.ts";
+
+export default async function runDev(site: Site): Promise<void> {
+	const server = new Server();
+
+	// Create the Vite server in middleware mode and configure the app type as
+	// "custom", disabling Vite's own HTML serving logic so the parent server
+	// can take control
+	const config = structuredClone(site.viteConfig ?? {});
+	config.server = { middlewareMode: true };
+	config.appType = "custom";
+	config.plugins = [manifest(site, true), torpor({ dev: true }), ...site.plugins];
+
+	// HACK: To be able to import `.torp` files from barrel files in
+	// node_modules, we need to add their libraries to `ssr.noExternal` in
+	// site.config.ts, and let esbuild know how to compile them here
+	config.optimizeDeps ??= {};
+	config.optimizeDeps.extensions ??= [];
+	config.optimizeDeps.extensions.push(".torp");
+	config.optimizeDeps.esbuildOptions ??= {};
+	config.optimizeDeps.esbuildOptions.plugins ??= [];
+	config.optimizeDeps.esbuildOptions.plugins.push(estorpor());
+
+	const vite = await createViteServer(config);
+
+	// Read site.html
+	// It's called site.html because @torpor/build builds the site (html, routes
+	// etc) while the user builds the app (components etc)
+	const templateFile = path.resolve(site.root, "src/site.html");
+	let template = await fs.readFile(templateFile, "utf-8");
+
+	// Apply Vite HTML transforms. This injects the Vite HMR client, and also
+	// applies HTML transforms from Vite plugins. Note that we only support a
+	// universal transform, not individual transforms for each route
+	template = await vite.transformIndexHtml("", template);
+
+	const siteFolder = path.resolve(site.root, "./node_modules/@torpor/build/src/site/");
+	let clientScript = path.join(siteFolder, "clientEntry.ts");
+	let clientDevScript = path.join(siteFolder, "clientEntryDev.ts");
+	let serverScript = path.join(siteFolder, "serverEntry.ts");
+
+	// Prepare site.html so that we can just splice components into it
+	template = prepareTemplate(template, clientScript, clientDevScript);
+
+	// Use Vite's Connect instance as middleware. We need to wrap it with
+	// createMiddlewareHandler that converts Connect middleware to
+	// Request/Response web handlers
+	server.use(connectMiddleware(vite.middlewares));
+
+	// Every request (GET, POST, etc) goes through loadEndPoint
+	server.add("*", async (ev) => {
+		try {
+			// Load the server entry. ssrLoadModule automatically transforms ESM
+			// source code to be usable in Node.js. No bundling is required, and
+			// it provides efficient invalidation similar to HMR
+			const { load } = await vite.ssrLoadModule(serverScript);
+
+			// Render the app HTML (or fetch server data etc) via serverEntry's
+			// exported `load` function
+			return await load(ev, template);
+		} catch (e: any) {
+			// If an error is caught, let Vite fix the stack trace so it maps
+			// back to your actual source code
+			vite.ssrFixStacktrace(e);
+			return serverError(e);
+		}
+	});
+
+	// Load environment variables from a `.env` file, with defaults if not set
+	configDotenv();
+
+	process.env.PROTOCOL ??= "http:";
+	process.env.HOST ??= "localhost";
+	process.env.PORT ??= "7059";
+
+	// Serve the site
+	site.adapter.serve(server, site);
+}