@marko/run 0.0.1-beta2 → 0.0.1-beta4

package/README.md

@@ -1,31 +1,33 @@
-<h1 align="center">
+<div align="center">
   <!-- Logo -->
-  <img src="https://user-images.githubusercontent.com/4985201/115444712-ca550500-a1c9-11eb-9897-238ece59129c.png" height="118"/>
-  <br/>
-  @marko/run
-	<br/>
+  <h1>
+    <img alt="" src="https://user-images.githubusercontent.com/4985201/115444712-ca550500-a1c9-11eb-9897-238ece59129c.png" height="118"/>
+    <br/>
+    @marko/run
+  </h1>
 
   <!-- Language -->
-  <a href="http://typescriptlang.org">
+  <a href="https://www.typescriptlang.org">
     <img src="https://img.shields.io/badge/%3C%2F%3E-typescript-blue.svg" alt="TypeScript"/>
   </a>
-</h1>
+</div>
 
-Vite plugin for Marko with these features
-- Encapsulates [@marko/vite](https://github.com/marko-js/vite)
+`@marko/serve` is a Vite plugin for [Marko](https://markojs.com), with these features:
+
+- Encapsulates [`@marko/vite`](https://github.com/marko-js/vite)
 - File-based routing with layouts and middleware
 - Efficient routing using a compiled static trie
-- Designed with web standards to run anywhere
+- [Designed with web standards](https://developer.mozilla.org/en-US/docs/Web/API/URLPattern/URLPattern) to run anywhere
 
-## Intallation
+## Installation
 
-```
+```sh
 npm install @marko/run
 ```
 
 ## Vite Plugin
 
-This package provides both a Vite plugin and a runtime import. The Vite plugin is responsible for discovering your route files, generating the routing code and registering the @marko/vite plugin which builds your .marko files.
+This package’s Vite plugin discovers your route files, generates the routing code, and registers the `@marko/vite` plugin to compile your `.marko` files.
 
 ```ts
 // vite.config.ts
@@ -35,27 +37,32 @@ import marko from "@marko/run/vite"; // Import the Vite plugin
 export default defineConfig({
   plugins: [marko()], // Register the Vite plugin
   build: {
-    sourcemap: true, // Generate sourcemaps for all builds.
-    emptyOutDir: false, // Avoid server & client deleting files from each other.
+    sourcemap: true, // Generate sourcemaps for all builds
+    emptyOutDir: false, // Avoid server & client deleting files from each other. TODO: do we have to make the user set this themselves?
   }
 })
 ```
 
 ## Runtime
 
-Generally you'll want to use one of the adapters to provide a more convenient experience but this package provides the following runtime interface:
+Generally, using one of the adapters is more convenient <!-- TODO: is an “adapter” the same thing as using the Vite plugin above? -->, but this package also provides a runtime API:
 
 ```ts
 import { router, getMatchedRoute } from '@marko/run`;
 ```
 
 ### `router`
+
 ```ts
 (request: Request) => Promise<Response>;
 ```
-This asynchronouse function takes a [WHATWG request](https://fetch.spec.whatwg.org/#request-class) object and returns a [response](https://fetch.spec.whatwg.org/#response-class) object generated by executing the corresponding matched route files. If no match is found, a response with a 404 status code is returned. If an unhandled error occurs, a response with a 500 status code will be returned.
+
+This asynchronous function takes a [WHATWG `Request` object](https://fetch.spec.whatwg.org/#request-class) and returns a [`Response` object](https://fetch.spec.whatwg.org/#response-class) generated by executing any matched route files.
+
+If no match is found, returns a response with a `404` status code. If an unhandled error occurs, returns a response with a `500` status code.
 
 ### `getMatchedRoute`
+
 ```ts
 (method: string, url: URL) => {
   params: Record<string, string>;
@@ -63,20 +70,25 @@ This asynchronouse function takes a [WHATWG request](https://fetch.spec.whatwg.o
   invoke(request: Request): Promise<Response>;
 } | null;
 ```
-This synchronous function takes a HTTP verb method, and URL and returns an object representing the best match or null if no match is found.
-- `params` - a key-value collection of any path parameters for the route
-- `meta` - meta data for the route
-- `invoke` - an asynchronouse function that takes a WHATWG request and returns the response generated by executing the matched route files. Note: unlike the top-level `router` function errors will not be caught.
+
+This synchronous function takes an HTTP method + URL, then returns an object representing the best match — or `null` if no match is found.
+
+- `params` - a `{ key: value }` collection of any path parameters for the route
+- `meta` - metadata for the route
+- `invoke` - an asynchronous function that takes a `Request` and returns the `Response` generated from matched route files.
+  > **Note**: unlike the top-level `router` function, errors will not be caught.
 
 ## File-based Routing
 
-## Nested Routing
+### Nested Routing
 
-*TODO: provide a quick overview*
+*🎗 TODO: provide a quick overview*
 
 ### Routes Directory
 
-By default, the plugin will look for files in the configured _routes directory_. By default it will look in `./src/routes` (relative to the Vite config file) which can be configured:
+The plugin looks for route files in the configured **routes directory**. By default, that’s `./src/routes`, relative to the Vite config file.
+
+To change what directory routes are found in:
 
 ```ts
 // vite.config.ts
@@ -86,55 +98,56 @@ import marko from "@marko/run/vite";
 export default defineConfig({
   plugins: [marko({
     routesDir: 'src/pages' // Use `./src/pages` (relative to this file) as the routes directory
-  })],
-  //...
+  })]
 })
 ```
 
 ### Routeable Files
 
-In order to allow for co-location of files that should not be served (e.g. tests, stories, assets), the router only recognizes a specific set of file names. The following files will be discovered in any directory within your application's _routes directory_.
+To allow for colocation of files that shouldn’t be served (like tests, assets, etc.), the router only recognizes certain filenames.
+
+The following filenames will be discovered in any directory inside your application’s [routes directory](#routes-directory).
 
 #### `+page.marko`
-These files establish a route at the current directory path which will be served for GET requests with the HTML content of the page. Only one page may exists for any served path.
+
+These files establish a route at the current directory path which will be served for `GET` requests with the HTML content of the page. Only one page may exists for any served path.
 
 #### `+layout.marko`
-These files provide a layout component which will wrap all nested layouts and pages.
 
-<details>
-  <summary>More Info</summary>
-  
-  Layouts are just like any other Marko component with no extra constraints. Each layout receives the request, path params, URL and route meta data as input as well as a renderBody which will be the subsequent layout or page to project. 
-
-  ```marko
-  <div>
-    <h1>My Products</h1>
-    <main>
-      ${input.renderBody} // project the page or layout here
-    </main>
-  </div>
-  ```
-</details>
+These files provide a **layout component**, which will wrap all nested layouts and pages.
+
+Layouts are like any other Marko component with no extra constraints. Each layout receives the request, path params, URL, and route metadata as input, as well as a `renderBody` which will be the next layout or page to project. 
+
+```marko
+<main>
+  <h1>My Products</h1>
+
+  ${input.renderBody} // render the page or layout here
+</main>
+```
 
 #### `+handler.*`
-These files establish a route at the current directory path which can handle requests for GET, POST, PUT and DELETE HTTP verbs. Typically these will be .js or .ts files depending on your project. Just like pages, only one handler may exist for any served path. A handler should export functions
+
+These files establish a route at the current directory path which can handle requests for `GET`, `POST`, `PUT`, and `DELETE` HTTP methods. <!-- TODO: what about HEAD? -->
+
+Typically, these will be `.js` or `.ts` files depending on your project. Like pages, only one handler may exist for any served path. A handler should export functions
 
 <details>
   <summary>More Info</summary>
   
-  - Valid exports are: `get`, `post`, `put`, `del`.
-  - Each method takes a `context` and `next` argument and should return a WHATWG response either synchronously or asynchronously.
-  - The `context` argument contains the WHATWG request object, path parameters, URL and route meta data.
-  - The `next` argument will call the page for get requests where applicable or return a 204 response.
+  - Valid exports are functions named `get`, `post`, `put`, or `del`.
+  - Each export receives a `context` and `next` argument, and should return a WHATWG `Response` either synchronously or asynchronously.
+    - The `context` argument contains the WHATWG request object, path parameters, URL, and route metadata.
+    - The `next` argument will call the page for get requests where applicable or return a `204` response.
 
-  ```ts
+  ```js
   export function post(context, next) {
     const { request, params, url, meta } = context;
-    return new Response('updated', { status: 200 });
+    return new Response('Successfully updated', { status: 200 });
   }
 
   export function put(context, next) {
-    return new Response('created', { status: 201 }); // handle the request
+    return new Response('Successfully created', { status: 201 }); // handle the request
   }
 
   export function get(context, next) {
@@ -142,29 +155,33 @@ These files establish a route at the current directory path which can handle req
   }
 
   export function del(context, next) {
-    return new Response('removed', { status: 204 });
+    return new Response('Successfully removed', { status: 204 });
   }
   ```
 </details>
 
 
-#### `+middlware.*`
-These files are analagous to layouts for handlers. Middlware get called before handlers and let you perform arbitrary work before and after. Unlike handlers, middleware run for all HTTP verbs.
+#### `+middleware.*`
+
+These files are like layouts, but for handlers. Middleware get called before handlers and let you perform arbitrary work before and after.
+
+> **Note**: Unlike handlers, middleware run for all HTTP methods.
 
 <details>
   <summary>More Info</summary>
   
-  - Expects default export that takes a `context` and `next` argument and should return a WHATWG response either synchronously or asynchronously.
-  - The `context` argument contains the WHATWG request object, path parameters, URL and route meta data.
-  - The `next` argument will call the next middleware, handler or page as applicable for the route.
+  Expects a `default` export that receives a `context` and `next` argument, and should return a WHATWG response either synchronously or asynchronously.
+	
+  - The `context` argument contains the WHATWG `Request` object, path parameters, URL, and route metadata.
+  - The `next` argument will call the next middleware, handler, or page for the route.
 
   ```ts
   export default async function(context, next) {
-    const requestName = `${ctx.request.method} ${ctx.url.href}`;
+    const requestName = `${ctx.request.method} ${ctx.url.href}`; // TODO: could this be just `ctx.url` with a `toString` that then grabs `.href`?
     let success = true;
     console.log(`${requestName} request started`)
     try {
-      return await next(); // wait for subsequent middleware/handler/page
+      return await next(); // Wait for subsequent middleware/handler/page
     } catch (err) {
       success = false;
       throw err;
@@ -176,30 +193,42 @@ These files are analagous to layouts for handlers. Middlware get called before h
 </details>
 
 #### `+meta.*`
-These files represent some meta data to attach to the route. This meta data will be automatically imported by the router and provided on the the route context when invoking a route. 
+
+These files represent metadata to attach to the route. This metadata will be automatically provided on the the route `context` when invoking a route. 
 
 ### Special Files
 
-In addition to the files above which can be defined in any directory under the _routes directory_, there are some special files which can only be defined within the _routes directory_:
+In addition to the files above which can be defined in any directory under the _routes directory_, there are some special files which can only be defined at the top-level of the _routes directory_. <!-- TODO: do we want to keep this restriction? Having nested 404s would be handy for disambiguating things like “there’s no user with that name” or “that promotion wasn’t found, it may have expired” -->
+
+These special pages are subject to a root layout file (`pages/+layout.marko` in the default configuration).
 
 #### `+404.marko`
-This is a special page wich will be rendered for any request whose `Accept` header includes `text/html` if no other handler or page handled the request. This page will be subject to the root layout file (ie. +layout.marko file in the _routes directory_). Responses with this page will have a `404` status code.
+
+This special page responds to any request where:
+
+- The `Accept` request header includes `text/html`
+- *And* no other handler or page rendered the request
+
+Responses with this page will have a `404` status code.
 
 #### `+500.marko`
-This is a special page wich will be rendered for any request whose `Accept` header includes `text/html` if an uncaught error occurs while handling the request. This page will be subject to the root layout file (ie. +layout.marko file in the _routes directory_). Responses with this page will have a `500` status code.
 
+This special page responds to any request where:
+
+- The `Accept` request header includes `text/html`
+- *And* an uncaught error occurs while serving the request
+
+Responses with this page will have a `500` status code.
 
 ### Execution Order
 
-For a matched route the routable files execute in the following order
+For a matched route, the routable files execute in the following order:
+
 1. Middlewares from root-most to leaf-most
 2. Handler
 3. Layouts from root-most to leaf-most
 4. Page
 
-<details>
-  <summary>Diagram</summary>
-
 ```mermaid
 sequenceDiagram
     participant Middleware1
@@ -218,13 +247,12 @@ sequenceDiagram
     Handler-->>Middleware2: Response
     Middleware2-->>Middleware1: Response
 ```
-</details>
 
 ### Path Structure
 
-Within the _routes directory_ the directory structure will determine the path the route will be served. There are four types of directory names:
+Within the _routes directory_, the directory structure will determine the path the route will be served. There are four types of directory names: static, pathless, dynamic, and catch-all.
 
-- **Static directories** - The most common type of directory. Each static directory will contribute its name as a segment in the route's served path like a traditional file server. This is the default and unless the directory matches the requirements for one of the below types, it will be a static directory.
+1. **Static directories** - The most common type. Each static directory contributes its name as a segment in the route's served path, like a traditional fileserver. Unless a directory name matches the requirements for one of the below types, it defaults to a static directory.
 
   Examples:
   ```
@@ -233,7 +261,7 @@ Within the _routes directory_ the directory structure will determine the path th
   /projects
   ```
 
-- **Pathless directories** - These directories do not contribute their name to the route's served path. Directory names that start with an underscore ('_') as well as directories named 'index' will be a pathless directory.
+2. **Pathless directories** - These directories do **not** contribute their name to the route's served path. Directory names that start with an underscore (`_`) or directories named `index` will be a pathless directory.
 
   Examples:
   ```
@@ -242,7 +270,7 @@ Within the _routes directory_ the directory structure will determine the path th
   /index
   ```
 
-- **Dynamic directories** - These directories introduce a dynamic parameter to the route's served path and will match any value at that segment. Any directory name that starts with a single dollar sign ('\$') will be a dynamic directory and the remaining directory name will be the parameter at runtime. In the case the directory name is '$', the parameter will not exist at runtime but will be matched.
+3. **Dynamic directories** - These directories introduce a dynamic parameter to the route's served path and will match any value at that segment. Any directory name that starts with a single dollar sign (`$`) will be a dynamic directory, and the remaining directory name will be the parameter at runtime. If the directory name is exactly `$/`, the parameter will not exist at runtime but will be matched.
 
   Examples:
   ```
@@ -251,9 +279,9 @@ Within the _routes directory_ the directory structure will determine the path th
   /$
   ```
 
-- **Catcha-all directories** - These directories are similar to dynamic directories and introduce a dynamic parameter but instead of matching a single sement of the path, they match to the end of the path. Any directory that starts with two dollar signs ('\$\$') will be a catch-all directory and the remaining directory name will be the parameter at runtime. In the case of a directory name '$$', the parameter name at runtime will be '*'. Catch-all directories can be used to make not found/404 routes at any level including the root.
+4. **Catch-all directories** - These directories are similar to dynamic directories and introduce a dynamic parameter, but instead of matching a single path segment, they match to the end of the path. Any directory that starts with two dollar signs (`$$`) will be a catch-all directory, and the remaining directory name will be the parameter at runtime. In the case of a directory named `$$/`, the parameter name at runtime will be `*`. Catch-all directories can be used to make `404` Not Found routes at any level, including the root.
 
-  Because catch-all directories always match and consume all the remaining path, you cannot have nested routes within and no further directories will be traversed.
+  Because catch-all directories match any path segment and consume the rest of the path, you cannot nest route files in them and no further directories will be traversed.
 
   Examples:
   ```

package/dist/adapter/default-entry.mjs

@@ -1,12 +1,16 @@
 import createStaticServe from "serve-static";
+import compression from "compression";
 import { createServer } from "http";
-import { createMiddleware } from "@hattip/adapter-node";
-import { handler } from "@marko/run/router";
+import createMiddleware from "@marko/run/adapter/middleware";
+import { router } from "@marko/run/router";
 
 const { PORT = 3456 } = process.env;
 
 const dir = process.cwd();
-const middleware = createMiddleware(handler);
+const middleware = createMiddleware(router);
+const compress = compression({
+  threshold: 500,
+});
 const staticServe = createStaticServe(dir, {
   index: false,
   immutable: true,
@@ -14,5 +18,7 @@ const staticServe = createStaticServe(dir, {
 });
 
 createServer((req, res) =>
+  compress(req, res, () => 
   staticServe(req, res, () => middleware(req, res))
+  )
 ).listen(PORT);

package/dist/adapter/dev-server.d.ts

@@ -1,4 +1,4 @@
 import { ViteDevServer } from "vite";
-import { type NodeMiddleware } from "@hattip/adapter-node";
+import { type NodeMiddleware } from "./middleware";
 export declare function createViteDevMiddleware<T>(devServer: ViteDevServer, load: (prev: T | undefined) => Promise<T>, factory: (value: T) => NodeMiddleware): NodeMiddleware;
 export declare function createDevServer(configFile?: string): Promise<import("vite").Connect.Server>;

package/dist/adapter/index.cjs

@@ -36,7 +36,173 @@ var import_url = require("url");
 
 // src/adapter/dev-server.ts
 var import_vite = require("vite");
-var import_adapter_node = require("@hattip/adapter-node");
+
+// src/adapter/middleware.ts
+var webStream = __toESM(require("stream/web"), 1);
+var import_crypto = __toESM(require("@hattip/polyfills/crypto"), 1);
+(0, import_crypto.default)();
+for (const key of Object.keys(webStream)) {
+  if (!(key in global)) {
+    global[key] = webStream[key];
+  }
+}
+function getForwardedHeader(req, name) {
+  const value = req.headers["x-forwarded-" + name];
+  if (value) {
+    if (typeof value === "string") {
+      const index = value.indexOf(",");
+      return index < 0 ? value : value.slice(0, index);
+    }
+    return value[0];
+  }
+}
+function getOrigin(req, protocol, host, trustProxy) {
+  var _a;
+  protocol ?? (protocol = req.protocol || trustProxy && getForwardedHeader(req, "proto") || ((_a = req.socket) == null ? void 0 : _a.encrypted) && "https" || "http");
+  host ?? (host = trustProxy && getForwardedHeader(req, "host") || req.headers.host);
+  if (!host) {
+    if (process.env.NODE_ENV !== "production") {
+      host = "localhost";
+      console.warn(
+        `Could not automatically determine the origin host, using 'localhost'. Use the 'origin' option or the 'ORIGIN' environment variable to set the origin explicitly.`
+      );
+    } else {
+      throw new Error(
+        `Could not automatically determine the origin host. Use the 'origin' option or the 'ORIGIN' environment variable to set the origin explicitly.`
+      );
+    }
+  }
+  return `${protocol}://${host}`;
+}
+function createMiddleware(router, options = {}) {
+  const { trustProxy = process.env.TRUST_PROXY === "1" } = options;
+  let { origin = process.env.ORIGIN } = options;
+  let protocol;
+  let host;
+  if (origin) {
+    ({ protocol, host } = new URL(origin));
+    protocol = protocol.slice(0, -1);
+  }
+  return async (req, res, next) => {
+    origin ?? (origin = getOrigin(req, protocol, host, trustProxy));
+    const url = new URL(req.url, origin);
+    const ip = req.ip || trustProxy && getForwardedHeader(req, "for") || req.socket.remoteAddress || "";
+    const requestContext = {
+      method: req.method,
+      url,
+      platform: {
+        ip,
+        request: req,
+        response: res,
+        setCookie(cookie) {
+          res.appendHeader("set-cookie", cookie);
+        }
+      }
+    };
+    Object.defineProperty(requestContext, "request", {
+      get() {
+        const headers = req.headers;
+        const body = req.method === "GET" || req.method === "HEAD" ? void 0 : req.socket ? req : new ReadableStream({
+          start(controller) {
+            req.on("data", (chunk) => controller.enqueue(chunk));
+            req.on("end", () => controller.close());
+            req.on("error", (err) => controller.error(err));
+          }
+        });
+        const request = new Request(url, {
+          method: req.method,
+          headers,
+          body,
+          duplex: "half"
+        });
+        Object.defineProperty(this, "request", {
+          value: request,
+          enumerable: true,
+          configurable: true
+        });
+        return request;
+      },
+      enumerable: true,
+      configurable: true
+    });
+    const response = await router(requestContext);
+    if (!response) {
+      if (next) {
+        next();
+      } else {
+        res.statusCode = 404;
+        res.setHeader("content-length", "0");
+        res.end();
+        return;
+      }
+      return;
+    }
+    res.statusCode = response.status;
+    for (const [key, value] of response.headers) {
+      if (key === "set-cookie") {
+        let sepIndex = value.indexOf(",") + 1;
+        if (!sepIndex) {
+          res.setHeader(key, value);
+        } else {
+          let index = 0;
+          do {
+            res.appendHeader(key, value.slice(index, sepIndex - 1));
+            index = sepIndex;
+            sepIndex = value.indexOf(",", sepIndex) + 1;
+          } while (sepIndex);
+          res.appendHeader(key, value.slice(index));
+        }
+      } else {
+        res.setHeader(key, value);
+      }
+    }
+    if (!response.body) {
+      if (!response.headers.has("content-length")) {
+        res.setHeader("content-length", "0");
+      }
+      res.end();
+      return;
+    }
+    const reader = response.body.getReader();
+    if (res.destroyed) {
+      reader.cancel();
+      return;
+    }
+    res.on("close", cancel);
+    res.on("error", cancel);
+    write();
+    function cancel(error) {
+      res.off("close", cancel);
+      res.off("error", cancel);
+      reader.cancel(error).catch(() => {
+      });
+      error && res.destroy(error);
+    }
+    async function write() {
+      try {
+        while (true) {
+          const { done, value } = await reader.read();
+          if (done) {
+            res.end();
+            return;
+          } else if (!res.write(value)) {
+            res.once("drain", write);
+            return;
+          } else if (res.flush) {
+            res.flush();
+          }
+        }
+      } catch (err) {
+        const error = err instanceof Error ? err : new Error("Error while writing to node response", {
+          cause: err
+        });
+        cancel(error);
+      }
+    }
+  };
+}
+
+// src/adapter/dev-server.ts
 function createViteDevMiddleware(devServer, load, factory) {
   let value;
   let middleware;
@@ -64,8 +230,8 @@ async function createDevServer(configFile) {
   });
   const middleware = createViteDevMiddleware(
     devServer,
-    async () => (await devServer.ssrLoadModule("@marko/run/router")).handler,
-    import_adapter_node.createMiddleware
+    async () => (await devServer.ssrLoadModule("@marko/run/router")).router,
+    createMiddleware
   );
   return devServer.middlewares.use(middleware);
 }
@@ -73,16 +239,30 @@ async function createDevServer(configFile) {
 // src/vite/utils/server.ts
 var import_net = __toESM(require("net"), 1);
 var import_child_process = __toESM(require("child_process"), 1);
-async function spawnServer(cmd, port = 0, cwd = process.cwd(), wait = 3e4) {
+var import_dotenv = require("dotenv");
+var import_fs = __toESM(require("fs"), 1);
+async function parseEnv(envFile) {
+  if (import_fs.default.existsSync(envFile)) {
+    const content = await import_fs.default.promises.readFile(envFile, "utf8");
+    return (0, import_dotenv.parse)(content);
+  }
+}
+function loadEnv(envFile) {
+  (0, import_dotenv.config)({ path: envFile });
+}
+async function spawnServer(cmd, port = 0, env, cwd = process.cwd(), wait = 3e4) {
   if (port <= 0) {
     port = await getAvailablePort();
   }
+  if (typeof env === "string") {
+    env = await parseEnv(env);
+  }
   const proc = import_child_process.default.spawn(cmd, {
     cwd,
     shell: true,
     stdio: "inherit",
     windowsHide: true,
-    env: { NODE_ENV: "development", ...process.env, PORT: `${port}` }
+    env: { ...env, NODE_ENV: "development", ...process.env, PORT: `${port}` }
   });
   const close = () => {
     proc.unref();
@@ -136,7 +316,8 @@ function adapter() {
       const entry = import_path.default.join(__dirname, "default-entry");
       return entry;
     },
-    async startDev(configFile, port) {
+    async startDev(configFile, port, envFile) {
+      envFile && await loadEnv(envFile);
       const server = await createDevServer(configFile);
       return new Promise((resolve) => {
         const listener = server.listen(port, () => {
@@ -146,8 +327,8 @@ function adapter() {
         });
       });
     },
-    async startPreview(dir, entry, port) {
-      const server = await spawnServer(`node ${entry}`, port, dir);
+    async startPreview(dir, entry, port, envFile) {
+      const server = await spawnServer(`node ${entry}`, port, envFile, dir);
       console.log(`Preview server started: http://localhost:${server.port}`);
     }
   };

package/dist/adapter/index.d.ts

@@ -1,4 +1,5 @@
 import type { Adapter } from "../vite";
 export { createDevServer, createViteDevMiddleware } from "./dev-server";
 export type { Adapter };
+export type { NodePlatformInfo } from './middleware';
 export default function adapter(): Adapter;