@torpor/build 1.0.0 → 1.0.1

package/src/response/forbidden.ts

@@ -1,21 +0,0 @@
-import response from "./response";
-
-/**
- * 403 Forbidden
- *
- * The HTTP 403 Forbidden client error response status code indicates that the
- * server understood the request but refused to process it. This status is
- * similar to 401, except that for 403 Forbidden responses, authenticating or
- * re-authenticating makes no difference. The request failure is tied to
- * application logic, such as insufficient permissions to a resource or action.
- *
- * Clients that receive a 403 response should expect that repeating the request
- * without modification will fail with the same error. Server owners may decide
- * to send a 404 response instead of a 403 if acknowledging the existence of a
- * resource to clients with insufficient privileges is not desired.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403
- */
-export default function forbidden(body?: object | string): Response {
-	return response(403, body ?? "Forbidden");
-}

package/src/response/found.ts

@@ -1,30 +0,0 @@
-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 found(location: string): Response {
-	return transfer(302, location);
-}

package/src/response/methodNotAllowed.ts

@@ -1,18 +0,0 @@
-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

@@ -1,25 +0,0 @@
-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 movedPermanently(location: string): Response {
-	return transfer(301, location);
-}

package/src/response/notFound.ts

@@ -1,24 +0,0 @@
-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

@@ -1,34 +0,0 @@
-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(): Response {
-	return transfer(304, "");
-}

package/src/response/ok.ts

@@ -1,38 +0,0 @@
-import type { Jsonify } from "../types/Jsonify";
-import type TypedResponse from "./TypedResponse";
-import response from "./response";
-
-type OkResponse<T extends object | string | undefined> = T extends object
-	? TypedResponse<Jsonify<T>>
-	: Response;
-
-/**
- * 200 OK
- *
- * The HTTP 200 OK successful response status code indicates that a request has
- * succeeded. A 200 OK response is cacheable by default.
- *
- * A 200 OK response has a different meaning and format depending on the HTTP
- * request method. Here's how they vary for different methods:
- *
- * - GET: A resource was retrieved by the server and included in the response
- *   body.
- * - POST: An action succeeded; the response has a message body describing the
- *   result.
- * - HEAD: Identical to GET, except there is no message body.
- * - TRACE: The response has a message body containing the request as received
- *   by the server.
- *
- * Although possible, successful PUT or DELETE requests often do not result in
- * a 200 OK response. It is more common to see 201 Created if the resource is
- * uploaded or created for the first time, or 204 No Content upon successful
- * deletion of a resource.
- *
- * An object body is typed: the client sees its JSON form through
- * `makeApi`-created callers.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200
- */
-export default function ok<T extends object | string | undefined>(body?: T): OkResponse<T> {
-	return response(200, body) as OkResponse<T>;
-}

package/src/response/permanentRedirect.ts

@@ -1,30 +0,0 @@
-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

@@ -1,22 +0,0 @@
-/**
- * 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

@@ -1,19 +0,0 @@
-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

@@ -1,24 +0,0 @@
-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

@@ -1,31 +0,0 @@
-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

@@ -1,14 +0,0 @@
-/**
- * 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

@@ -1,21 +0,0 @@
-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

@@ -1,30 +0,0 @@
-import response from "./response";
-import type { Jsonify } from "../types/Jsonify";
-import type TypedResponse from "./TypedResponse";
-
-type UnprocessableResponse<T extends object | string | undefined> = T extends object
-	? TypedResponse<Jsonify<T>>
-	: Response;
-
-/**
- * 422 Unprocessable Content
- *
- * The HTTP 422 Unprocessable Content client error response status code
- * indicates that the server understood the content type of the request content,
- * and the syntax of the request content was correct, but it was unable to
- * process the contained instructions.
- *
- * Clients that receive a 422 response should expect that repeating the request
- * without modification will fail with the same error.
- *
- * An object body is typed: it becomes the page's `$props.form` (with its JSON
- * form) after a form submit, so validation errors can be surfaced with their
- * field types via `PageForm`.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/422
- */
-export default function unprocessable<T extends object | string | undefined>(
-	body?: T,
-): UnprocessableResponse<T> {
-	return response(422, body ?? "Unprocessable") as UnprocessableResponse<T>;
-}

package/src/response.ts

@@ -1,37 +0,0 @@
-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/depCache.ts

@@ -1,175 +0,0 @@
-import { createHash } from "node:crypto";
-import {
-	existsSync,
-	readFileSync,
-	readdirSync,
-	realpathSync,
-	rmSync,
-	statSync,
-	writeFileSync,
-} from "node:fs";
-import { createRequire } from "node:module";
-import path from "node:path";
-import type { PackageJson } from "../utils/torporPackages";
-
-/**
- * Vite's dep-optimization cache (node_modules/.vite) keys off the lockfile
- * and config, but not the content of workspace packages. When a workspace
- * package is rebuilt while the cache holds prebundled copies of it, dev SSR
- * keeps executing the stale modules -- producing bizarre errors (missing
- * runtime identifiers, "$cache must be used in a getter", ...) that only a
- * manual cache delete fixes.
- *
- * clearStaleDepCache runs at `tb --dev` startup: it fingerprints every
- * workspace package the site depends on (path, size and mtime of each file)
- * and, when the fingerprint differs from the previous run, deletes the cache
- * so Vite re-optimizes from the rebuilt packages.
- *
- * Live rebuilds while the server is up are still not hot-invalidated (that
- * needs a watcher feeding Vite's module graph); this closes the "restart and
- * hope you remember the trick" gap.
- */
-
-const STORE_NAME = ".torpor-dev-cache.json";
-
-/**
- * Clears site/node_modules/.vite when workspace packages changed since the
- * last dev run. Returns true when the cache was removed.
- */
-export function clearStaleDepCache(siteRoot: string, log?: (message: string) => void): boolean {
-	try {
-		const workspaceRoot = findWorkspaceRoot(siteRoot);
-		if (!workspaceRoot) return false;
-
-		const cacheDir = path.join(siteRoot, "node_modules", ".vite");
-		const storePath = path.join(siteRoot, "node_modules", STORE_NAME);
-
-		const fingerprint = fingerprintWorkspacePackages(siteRoot, workspaceRoot);
-		if (fingerprint === undefined) return false;
-
-		const previous = readStore(storePath);
-
-		let cleared = false;
-		if (existsSync(cacheDir) && previous !== fingerprint) {
-			rmSync(cacheDir, { recursive: true, force: true });
-			cleared = true;
-			log?.("Workspace packages changed; clearing the Vite dep cache");
-		}
-		writeFileSync(storePath, JSON.stringify({ fingerprint }));
-
-		return cleared;
-	} catch (e) {
-		if (process.env.TORPOR_DEBUG_CACHE) throw e;
-		// Never break dev startup over cache bookkeeping
-		return false;
-	}
-}
-
-export function findWorkspaceRoot(from: string): string | undefined {
-	let dir = path.resolve(from);
-	while (true) {
-		// pnpm-style marker, or a root package.json declaring npm workspaces
-		if (existsSync(path.join(dir, "pnpm-workspace.yaml"))) {
-			return dir;
-		}
-		if (hasWorkspacesField(dir)) {
-			return dir;
-		}
-		const parent = path.dirname(dir);
-		if (parent === dir) return undefined;
-		dir = parent;
-	}
-}
-
-function hasWorkspacesField(dir: string): boolean {
-	const packageJsonPath = path.join(dir, "package.json");
-	if (!existsSync(packageJsonPath)) return false;
-	try {
-		const pkg: PackageJson = JSON.parse(readFileSync(packageJsonPath, "utf8"));
-		return Array.isArray(pkg.workspaces) && pkg.workspaces.length > 0;
-	} catch {
-		return false;
-	}
-}
-
-function readStore(storePath: string): string | undefined {
-	if (!existsSync(storePath)) return undefined;
-	try {
-		const store = JSON.parse(readFileSync(storePath, "utf8")) as { fingerprint?: string };
-		return store.fingerprint;
-	} catch {
-		return undefined;
-	}
-}
-
-/**
- * Resolves every site dependency that lives inside the workspace to its
- * package folder. Shared with the other dev-startup checks (e.g. the stale
- * .torp copy report), which need the same set of packages.
- */
-export function workspaceDependencyDirs(siteRoot: string, workspaceRoot: string): string[] {
-	const sitePackageJson = path.join(siteRoot, "package.json");
-	if (!existsSync(sitePackageJson)) return [];
-
-	const pkg: PackageJson = JSON.parse(readFileSync(sitePackageJson, "utf8"));
-	const require = createRequire(sitePackageJson);
-
-	const packageDirs = new Set<string>();
-	for (const name of dependencyNames(pkg)) {
-		const dir = resolvePackageDir(name, require);
-		if (dir && insideWorkspace(realpathSync(dir), workspaceRoot)) {
-			packageDirs.add(realpathSync(dir));
-		}
-	}
-	return [...packageDirs].sort();
-}
-
-function fingerprintWorkspacePackages(siteRoot: string, workspaceRoot: string): string | undefined {
-	const sitePackageJson = path.join(siteRoot, "package.json");
-	if (!existsSync(sitePackageJson)) return undefined;
-
-	const packageDirs = workspaceDependencyDirs(siteRoot, workspaceRoot);
-	if (packageDirs.length === 0) return undefined;
-
-	const hash = createHash("sha1");
-	for (let dir of packageDirs) {
-		hash.update(`package:${dir}\n`);
-		fingerprintDir(dir, dir, hash);
-	}
-	return hash.digest("hex");
-}
-
-function dependencyNames(pkg: PackageJson): string[] {
-	return [...Object.keys(pkg.dependencies ?? {}), ...Object.keys(pkg.devDependencies ?? {})];
-}
-
-function resolvePackageDir(name: string, require: NodeRequire): string | undefined {
-	try {
-		const packageJsonPath = require.resolve(`${name}/package.json`);
-		return path.dirname(packageJsonPath);
-	} catch {
-		return undefined;
-	}
-}
-
-function insideWorkspace(dir: string, workspaceRoot: string): boolean {
-	const relative = path.relative(workspaceRoot, dir);
-	return relative === "" || (!relative.startsWith("..") && !path.isAbsolute(relative));
-}
-
-function fingerprintDir(dir: string, root: string, hash: import("node:crypto").Hash): void {
-	for (let entry of readdirSync(dir, { withFileTypes: true })) {
-		if (entry.name === "node_modules" || entry.name === ".git") continue;
-		const full = path.join(dir, entry.name);
-		if (entry.isDirectory()) {
-			fingerprintDir(full, root, hash);
-			continue;
-		}
-		if (!entry.isFile()) continue;
-		const stats = statSync(full);
-		// NOTE: hash.update takes (data, encoding) -- join into one string
-		hash.update(
-			`file:${path.relative(root, full).replaceAll("\\", "/")}:${stats.size}:${Math.floor(stats.mtimeMs)}\n`,
-		);
-	}
-}