@uniflowed/vite 0.0.0-alpha.1 → 0.0.0-alpha.11

package/internal/rsc.js

@@ -0,0 +1,151 @@
+// @noflow
+//
+// Plain JavaScript: executed by the host that runs Vite, before any transform.
+//
+// The server/client split, as the bundler applies it.
+//
+// `crates/uf_rsc` decides which modules a `"use client"` boundary is reachable
+// from. That answer used to reach nothing: `virtual:uf/routes` emitted
+// `page: () => import(<file>)` for every route, `virtual:uf/client` imported
+// that table, and so every page in the application was a chunk of the *client*
+// bundle whether or not a browser had anything to do with it.
+//
+// This module is the first thing that reads the answer. What is done with it
+// is in `routesModuleSource`, including the one thing a dropped route keeps.
+//
+// # Why the unit is a route and not a module
+//
+// Dropping a single Server Component from the client bundle is what Next.js
+// does, and it works there because the browser is handed a Flight payload
+// describing the tree the server rendered. uf has no such payload yet:
+// `packages/router/client.js` hydrates by re-rendering the matched tree from
+// the same modules the server rendered it from, so a module missing from the
+// client bundle is a module React cannot hydrate. What *can* be dropped is a
+// route the browser never renders at all — one where no client boundary is
+// reachable from the page, its layouts, its loading fallbacks or the
+// boundaries that cover it. Nothing under it is ever re-rendered in the
+// browser, so nothing under it has to be shipped. See ubugeeei-prod/uf#350.
+//
+// # Why "unknown" means "ship it"
+//
+// The analysis scans `.js`. A page written as `.mdx`, a `.jsx` module, a file
+// past the scanner's size limit: none of them is in the manifest, and the
+// honest reading of a module the analysis never saw is that it might reach a
+// boundary. Every unknown answers `true`, so the split can only ever remove a
+// route uf has positively decided needs no browser — and a manifest that is
+// missing, unreadable, or written by an older uf removes nothing at all.
+
+import { readFileSync } from "node:fs";
+import path from "node:path";
+
+/** Environment variable naming the manifest, set by `uf build` and `uf dev`. */
+export const RSC_MANIFEST_ENV = "UF_RSC_MANIFEST";
+
+/**
+ * The manifest schema this understands.
+ *
+ * Version 1 published the client boundaries and nothing that said which
+ * modules sat *above* one, so it cannot answer the question this module asks.
+ * An older manifest is therefore refused rather than read optimistically: a
+ * missing `proximity` would read as `undefined`, compare unequal to
+ * `"reaches-boundary"`, and quietly drop every route from the client bundle.
+ */
+const SUPPORTED_VERSION = 2;
+
+/**
+ * Read the RSC manifest, or `null` when there is nothing usable to read.
+ *
+ * Never throws. The split is an optimisation over a build that is already
+ * correct without it, so no failure here may be a failure of the build.
+ *
+ * @param {string | undefined} file absolute path, from the environment
+ */
+export function readRscManifest(file) {
+  if (file == null || file === "") return null;
+  let parsed;
+  try {
+    parsed = JSON.parse(readFileSync(file, "utf8"));
+  } catch {
+    return null;
+  }
+  if (parsed == null || typeof parsed !== "object") return null;
+  if (parsed.version !== SUPPORTED_VERSION || !Array.isArray(parsed.modules)) return null;
+  return parsed;
+}
+
+/**
+ * Which modules the browser has to be able to evaluate, keyed by project path.
+ *
+ * A `"use client"` module is a client bundle root by definition, and
+ * `proximity` never says so about it — it is the far side of the boundary
+ * rather than a module above one — so both halves are asked. This mirrors
+ * `RscModule::requires_client_bundle` in `crates/uf_rsc/src/graph.rs`.
+ */
+function clientModules(manifest) {
+  const modules = new Map();
+  for (const module of manifest.modules) {
+    if (module == null || typeof module.path !== "string") continue;
+    modules.set(
+      module.path,
+      module.environment === "client" || module.proximity === "reaches-boundary",
+    );
+  }
+  return modules;
+}
+
+/**
+ * Whether `boundary`'s route path covers `route`'s.
+ *
+ * Deliberately "covers" and not "is nearest to". `packages/router` picks the
+ * nearest not-found and error boundary above a path at render time; asking the
+ * same question here would be a second implementation of that rule, and the
+ * two would disagree the first time either moved. Every boundary that could
+ * apply is counted instead, which can only decide that more routes need the
+ * browser than strictly do.
+ */
+function covers(boundaryPath, routePath) {
+  return (
+    boundaryPath === "/" || routePath === boundaryPath || routePath.startsWith(`${boundaryPath}/`)
+  );
+}
+
+/**
+ * Build the predicate `routesModuleSource` asks about each route.
+ *
+ * Returns `(route) => boolean`: true when the route's page module belongs in
+ * the client bundle. With no manifest every route answers true, which is the
+ * whole table and exactly what the build emitted before this existed.
+ *
+ * @param {object | null} manifest from {@link readRscManifest}
+ * @param {string} root absolute project root
+ * @param {{notFound?: Array<object>, errors?: Array<object>}} [boundaries]
+ *   the scanned table, so a boundary that needs the browser keeps the routes
+ *   it covers in the client bundle
+ */
+export function clientRouteFilter(manifest, root, boundaries = {}) {
+  if (manifest == null) return () => true;
+  const modules = clientModules(manifest);
+
+  const needed = (file) => {
+    if (typeof file !== "string") return true;
+    const relative = path.relative(root, file).split(path.sep).join("/");
+    const answer = modules.get(relative);
+    return answer === undefined ? true : answer;
+  };
+
+  const notFound = boundaries.notFound ?? [];
+  const errors = boundaries.errors ?? [];
+
+  return (route) => {
+    if (needed(route.page)) return true;
+    if (route.layouts.some(needed)) return true;
+    if ((route.loading ?? []).some((entry) => needed(entry.module))) return true;
+    for (const boundary of notFound) {
+      if (covers(boundary.path, route.path) && needed(boundary.page)) return true;
+    }
+    for (const boundary of errors) {
+      if (covers(boundary.path, route.path) && needed(boundary.module)) return true;
+    }
+    return false;
+  };
+}

package/internal/serve.js

@@ -0,0 +1,345 @@
+// @noflow
+//
+// Plain JavaScript: executed by the host that serves a build.
+//
+// Serving what `uf build` wrote — one request handler, behind two front doors.
+//
+// `uf build` writes three things: a client bundle and prerendered HTML in
+// `dist/`, and a server bundle in `.uf/build/server/server.js` that exports
+// `render`, `dispatch`, `runMiddleware`, `routes`, `middleware`, `notFound`
+// and `errors`. This module finds them, reads the client manifest, and hands
+// both to the handler `uf preview` and `uf start` mount.
+//
+// `uf preview` and `uf start` are the two front doors, and they share
+// everything below on purpose. A preview whose answers differ from the
+// production server's is worse than no preview, because it is checked and
+// believed. The difference between the two commands is which socket the
+// handler is bolted to, not what it decides:
+//
+//   preview — Vite's own preview server, with this handler behind its static
+//             middleware, so `vite.preview.proxy`, `vite.preview.https`,
+//             `headers` and `cors` are in effect and what is being checked is
+//             the build *as Vite serves it*.
+//   start   — `node:http`, with no bundler in the process, because a host
+//             running a production build should not need Vite installed to
+//             answer a request.
+//
+// # Where the answering actually happens
+//
+// Not here, any more. Every decision about *what* a request is answered with
+// lives in `@uniflowed/server` — `@uniflowed/server/fetch` for the application
+// half and `@uniflowed/server/node` for the files and the socket — and this
+// module is the part that is genuinely Vite's: finding the build on disk and
+// reading the manifest a Vite build wrote.
+//
+// It moved because of `uf build --adapter`. `tests/library/serve.test.js` said
+// what was wrong with the old arrangement while it was still the only one:
+// "`internal/serve.js` is the seam a deploy adapter will need, and naming it
+// in `exports` before one exists would be promising an interface nothing has
+// used yet." An adapter exists now, and it may not import this package —
+// `@uniflowed/vite` is the bundler, and the whole claim of deployable output
+// is that the host needs neither the bundler nor the toolchain. So the seam is
+// a package export of `@uniflowed/server`, and `uf preview`, `uf start` and
+// every adapter now answer out of one implementation instead of copies that
+// agree until they do not.
+//
+// # Why those imports are dynamic
+//
+// `@uniflowed/server` is Flow, and `driver.js` registers the loader hooks that
+// make Flow importable *in its body* — after every static import in this graph
+// has already been evaluated. So they are reached the same way the server
+// bundle is: with `await import`, from [`loadBuild`], which is the point at
+// which this process stops being plain JavaScript and starts being the
+// project's.
+//
+// # Who owns the request
+//
+// The host does, and none of the three handlers below: each of them has a
+// `Response` in hand rather than a response on the wire, and what `after()`
+// promises is the wire. [`withRequest`] is the shape for a caller that writes
+// into a Node response itself — `uf dev` and `uf preview` — and
+// `@uniflowed/server/node`'s `nodeListener` does the same thing for `uf start`
+// and for the `server.js` an adapter writes. Each of them begins the request
+// with `entry.beginRequest`, runs the whole of answering it inside `run`, and
+// settles it on the line after the last byte.
+//
+// It has to be the *entry's* `beginRequest` rather than one imported here: the
+// request lives in an `AsyncLocalStorage` belonging to one copy of
+// `@uniflowed/server`, and the copy that matters is the one inside the
+// application bundle. A host that resolved its own would begin a request the
+// application cannot see, and nothing would fail loudly — the guard would run,
+// the page would render, and every `cookies()` in it would throw as though no
+// host had run at all. See ubugeeei-prod/uf#389.
+
+import { readFile, stat } from "node:fs/promises";
+import path from "node:path";
+import { pathToFileURL } from "node:url";
+
+/**
+ * `@uniflowed/server`'s two halves, loaded once.
+ *
+ * Cached as the promise rather than the modules, so two concurrent callers
+ * share one import rather than racing to start two.
+ */
+let deploymentModules = null;
+function deployment() {
+  deploymentModules ??= Promise.all([
+    import("@uniflowed/server/fetch"),
+    import("@uniflowed/server/node"),
+    import("@uniflowed/server/cache"),
+  ]).then(([application, host, cache]) => ({ ...application, ...host, ...cache }));
+  return deploymentModules;
+}
+
+/**
+ * The cache `rendering.cache` describes, or `undefined` for no cache at all.
+ *
+ * `undefined` rather than a store with both switches off, and the difference is
+ * visible from an application: a handler with no `cache` installs nothing on
+ * the request, so `revalidateTag()` raises "there is not one here" instead of
+ * reporting that it expired nothing. A project that turned the cache off should
+ * be told that it did, not handed a cache that quietly does nothing.
+ *
+ * One store per server process, built when the handler is, which is the whole
+ * of what "in memory, per process" means in practice: `uf preview` and
+ * `uf start` each hold one, and two of them running at once share nothing.
+ *
+ * The store's own options are not configurable from `uf.config.js` and are not
+ * named here: `rendering.cache` has four keys and no fifth, and a parameter
+ * threaded through for a setting nobody can set would be the shape of
+ * configurability with none of the substance.
+ *
+ * @param {{route?: boolean, fetch?: boolean} | undefined} declared
+ * @param {(options?: object) => object} createCacheStore
+ */
+function cacheFor(declared, createCacheStore) {
+  const route = declared?.route === true;
+  const fetchCache = declared?.fetch === true;
+  if (!route && !fetchCache) return undefined;
+  return { store: createCacheStore(), route, fetch: fetchCache };
+}
+
+/**
+ * Everything a served build consists of.
+ *
+ * Read once at startup rather than per request: the manifest does not change
+ * while the server runs, and importing the server bundle again per request
+ * would re-evaluate every module in the application.
+ *
+ * `@uniflowed/server` is loaded here too, and not lazily on the first request:
+ * a missing or broken install should fail the command that starts the server,
+ * with the message the import raises, rather than a minute later inside
+ * whichever request happened to arrive first.
+ *
+ * @param {{root: string, outDir: string, serverDir: string}} build
+ */
+export async function loadBuild({ root, outDir, serverDir }) {
+  const distDir = path.resolve(root, outDir);
+  const entryFile = path.join(path.resolve(root, serverDir), "server.js");
+
+  // Named separately, because the two failures have different fixes and a
+  // combined "run uf build" would be wrong for one of them: a `dist/` with no
+  // server bundle beside it is what a `.uf/` that was cleaned looks like.
+  await readable(entryFile, `the server bundle is missing at ${entryFile}`);
+  const manifestFile = path.join(distDir, ".vite", "manifest.json");
+  await readable(manifestFile, `the client manifest is missing at ${manifestFile}`);
+
+  const manifest = JSON.parse(await readFile(manifestFile, "utf8"));
+  const entry = await import(pathToFileURL(entryFile).href);
+  await deployment();
+  return { entry, assets: assetsFromManifest(manifest), distDir };
+}
+
+async function readable(file, message) {
+  try {
+    await stat(file);
+  } catch {
+    throw new Error(`uf: ${message}; run \`uf build\` first`);
+  }
+}
+
+/**
+ * The tags a rendered document needs, from the client build's manifest.
+ *
+ * Two walks over the manifest, because the two answers are different. A
+ * `modulepreload` is worth emitting only for a chunk this document will
+ * certainly load, which is the entry's *static* imports. A stylesheet has to
+ * be emitted for anything the page might render, and the router loads every
+ * route module dynamically — so a stylesheet imported by a layout is reached
+ * through `dynamicImports` and through nothing else. Following only the static
+ * graph, as this did, meant a layout could import a stylesheet and the built
+ * HTML would silently ship without it.
+ *
+ * The cost is that a project with per-route stylesheets links all of them on
+ * every page. Narrowing that needs the route table to say which chunk each
+ * route came from, which the manifest alone cannot tell us.
+ *
+ * The entry is found by its `isEntry` flag rather than by key, because a
+ * virtual module's manifest key is an implementation detail of the bundler.
+ *
+ * This is the one piece of serving a build that is genuinely Vite's — a Vite
+ * manifest, read the way Vite writes it — which is why it stayed behind when
+ * the rest moved to `@uniflowed/server`. `uf build --adapter` calls it too,
+ * at build time, and bakes the answer into what it emits.
+ */
+export function assetsFromManifest(manifest) {
+  const entry = Object.values(manifest).find((chunk) => chunk.isEntry);
+  if (entry == null) throw new Error("uf: the client manifest has no entry chunk");
+
+  const styles = new Set(entry.css ?? []);
+  const seen = new Set();
+  const collectStyles = (chunk) => {
+    for (const imported of [...(chunk.imports ?? []), ...(chunk.dynamicImports ?? [])]) {
+      if (seen.has(imported)) continue;
+      seen.add(imported);
+      const dependency = manifest[imported];
+      if (dependency == null) continue;
+      for (const css of dependency.css ?? []) styles.add(css);
+      collectStyles(dependency);
+    }
+  };
+  collectStyles(entry);
+
+  const preloads = new Set();
+  const collectPreloads = (chunk) => {
+    for (const imported of chunk.imports ?? []) {
+      const dependency = manifest[imported];
+      if (dependency == null || preloads.has(dependency.file)) continue;
+      preloads.add(dependency.file);
+      collectPreloads(dependency);
+    }
+  };
+  collectPreloads(entry);
+
+  return {
+    scripts: [`/${entry.file}`],
+    styles: [...styles].map((file) => `/${file}`),
+    preloads: [...preloads].map((file) => `/${file}`),
+  };
+}
+
+/**
+ * Answer one request inside it, and settle it when the answer has been written.
+ *
+ * `body` is everything that decides the response *and writes it*; this is the
+ * line after. `settle` is in a `finally` because a request that failed is
+ * still a request that happened: a middleware that logged the arrival is owed
+ * its callback whether the render threw or not, and `drainDeferred` already
+ * reports a failing task rather than propagating it.
+ *
+ * `entry.beginRequest` and not an import: the request lives in an
+ * `AsyncLocalStorage` belonging to one copy of `@uniflowed/server`, and the
+ * copy that matters is the one inside the application bundle. See
+ * `serverModuleSource` in `./routes.js`.
+ *
+ * The one case this cannot be exact about is a request uf hands back rather
+ * than answers: a caller whose `catch` is `next(error)` gives the response to
+ * Vite's chain, which writes a 500 at a moment nothing here can observe, so
+ * such a request settles when uf lets go of it. `nodeListener` and the
+ * compiled binary write their own failures and settle after them. It is worth
+ * naming rather than papering over, and it is the failure path of a request
+ * that already went wrong — not the ordinary one this exists for.
+ *
+ * @param {{beginRequest: (request: Request) => {run: <T>(body: () => Promise<T>) => Promise<T>, settle: () => Promise<void>}}} entry
+ * @param {Request} request
+ * @param {() => Promise<mixed>} body
+ */
+export async function withRequest(entry, request, body) {
+  const { run, settle } = entry.beginRequest(request);
+  try {
+    return await run(body);
+  } finally {
+    await settle();
+  }
+}
+
+/**
+ * The application half: route handlers, then rendering.
+ *
+ * `@uniflowed/server/fetch`'s `createFetchHandler`, reached through the
+ * dynamic import above. Kept as a function here — rather than making every
+ * caller await the module — because the two servers construct their handler
+ * before they take a socket, and an `await` in that position would put the
+ * import between the port and the first request rather than before both.
+ *
+ * It must be called inside a request its caller began; it begins none, because
+ * it has a `Response` in hand and not a response on the wire. A caller that
+ * forgets is not left to discover it: `entry.runMiddleware` refuses outside a
+ * request and names what establishes one. See "Who owns the request" above.
+ *
+ * `cache` is `rendering.cache` from `uf.config.js`, straight through: this is
+ * the point where four switches that used to reach a JSON file and nothing else
+ * become a store a request can hit. See ubugeeei-prod/uf#277.
+ *
+ * @param {{entry: object, assets: object, cache?: object}} build
+ */
+export function createApplicationHandler({ entry, assets, cache }) {
+  const ready = deployment().then(({ createFetchHandler, createCacheStore }) =>
+    createFetchHandler({
+      app: entry,
+      document: assets,
+      cache: cacheFor(cache, createCacheStore),
+    }),
+  );
+  return async function handle(request) {
+    return (await ready)(request);
+  };
+}
+
+/**
+ * The static half: a file under `root`, or `null` for the caller to carry on.
+ *
+ * `@uniflowed/server/node`'s, for the same reason as above: what a deployment
+ * runs and what `uf start` runs have to be the same code, not the same idea.
+ */
+export function createStaticHandler({ root }) {
+  const ready = deployment().then(({ createStaticHandler: create }) => create({ root }));
+  return async function serveStatic(request) {
+    return (await ready)(request);
+  };
+}
+
+/**
+ * Static files, then the application: the whole of what a built uf app serves.
+ *
+ * Static first, and that ordering is a compatibility requirement rather than a
+ * preference. Vite's preview server runs its own file middleware before
+ * anything added afterwards can see the request, so `uf preview` serves a file
+ * first whether or not this agrees — and `uf start` disagreeing would mean a
+ * project whose handler path collides with a file in `public/` behaves one way
+ * when it is checked and the other way when it is deployed.
+ *
+ * @param {{entry: object, assets: object, distDir: string, cache?: object}} build
+ */
+export function createServeHandler({ entry, assets, distDir, cache }) {
+  const serveStatic = createStaticHandler({ root: distDir });
+  const application = createApplicationHandler({ entry, assets, cache });
+  return async function handle(request) {
+    return (await serveStatic(request)) ?? (await application(request));
+  };
+}
+
+/**
+ * A `Request`/`Response` handler as a Node request listener.
+ *
+ * `@uniflowed/server/node`'s, which is also what the `server.js` an adapter
+ * writes runs — so a request reaching `uf start` and the same request reaching
+ * a deployed directory go through one translation rather than two, and settle
+ * at one moment rather than at two.
+ *
+ * `entry` is the second argument rather than something this reaches for: it is
+ * the application bundle's own `beginRequest` that has to own the request, for
+ * the reason in "Who owns the request" above. It is required, and a listener
+ * built without one fails on its first request — the same trade
+ * `createFetchHandler` makes about `app.runMiddleware`, and for the same
+ * reason: an optional lifecycle is a lifecycle somebody forgets, and what is
+ * lost when they do is every `after()` in the application.
+ */
+export function nodeListener(handle, entry) {
+  const ready = deployment().then(({ nodeListener: create }) =>
+    create(handle, { beginRequest: entry.beginRequest }),
+  );
+  return async function listener(incoming, outgoing) {
+    return (await ready)(incoming, outgoing);
+  };
+}

package/merge.js

@@ -0,0 +1,87 @@
+// @noflow
+//
+// Plain JavaScript: executed by the host that runs Vite, before any transform.
+//
+// Merging a project's own Vite configuration over the one uf generates.
+//
+// This exists because of a specific failure. uf's config re-declared Vite's
+// options one at a time — `host`, `port`, `strictPort`, `outDir`, `sourcemap`
+// — and the driver copied them across by hand. Anything Vite could do that uf
+// had not enumerated was unreachable until uf shipped a release naming it.
+// That is `react-scripts`: an integrated tool becoming the chokepoint every
+// upgrade in the ecosystem has to pass through.
+//
+// So `vite` in `uf.config.js` is Vite's own configuration, merged over uf's,
+// and uf makes no attempt to understand it. An option added to Vite tomorrow
+// works in a uf project tomorrow.
+//
+// # What uf still decides
+//
+// Three things are uf's rather than the project's, and the merge protects
+// them:
+//
+//   * `plugins`, which are concatenated rather than replaced — dropping uf's
+//     Flow transform would leave a project whose source no longer compiles,
+//     which is not a thing anyone means to configure.
+//   * `configFile`, because a `vite.config.ts` beside `uf.config.js` is two
+//     files disagreeing about one project.
+//   * `root`, which is the project uf resolved.
+//
+// Everything else is the project's to set, including options uf sets itself:
+// a default is a convenience, not an architecture.
+
+/** Keys uf owns outright, whatever the project's Vite config says. */
+const RESERVED = ["root", "configFile"];
+
+/**
+ * Deep-merge `overrides` onto `base`.
+ *
+ * Plain objects merge key by key; arrays and everything else replace, which is
+ * what a caller setting `build.rollupOptions.input` means. `plugins` is the
+ * exception and is handled by the caller, because concatenating is right there
+ * and replacing is right everywhere else.
+ */
+export function mergeConfig(base, overrides) {
+  if (overrides == null) return base;
+  const merged = { ...base };
+  for (const key of Object.keys(overrides)) {
+    const value = overrides[key];
+    if (value === undefined) continue;
+    merged[key] =
+      isPlainObject(value) && isPlainObject(base[key]) ? mergeConfig(base[key], value) : value;
+  }
+  return merged;
+}
+
+/**
+ * uf's generated config, with the project's Vite config merged over it.
+ *
+ * @param {object} generated what uf built from the semantics it owns
+ * @param {object | undefined} overrides `vite` from `uf.config.js`
+ */
+export function withProjectConfig(generated, overrides) {
+  if (overrides == null) return generated;
+
+  const owned = {};
+  for (const key of RESERVED) owned[key] = generated[key];
+
+  const merged = mergeConfig(generated, { ...overrides, ...owned });
+
+  // uf's plugins first, then the project's. First because the Flow transform
+  // has to see a module before anything that expects JavaScript does.
+  merged.plugins = [
+    ...(generated.plugins ?? []),
+    ...(Array.isArray(overrides.plugins) ? overrides.plugins : []),
+  ];
+  return merged;
+}
+
+function isPlainObject(value) {
+  return (
+    typeof value === "object" &&
+    value !== null &&
+    !Array.isArray(value) &&
+    // A plugin, a logger or a URL is a value to replace, not a shape to merge.
+    (Object.getPrototypeOf(value) === Object.prototype || Object.getPrototypeOf(value) === null)
+  );
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniflowed/vite",
-  "version": "0.0.0-alpha.1",
+  "version": "0.0.0-alpha.11",
   "description": "Vite, driven by uf.config.js: every Flow module through `uf transform`, MDX, the file-system router and static rendering as Vite plugins.",
   "type": "module",
   "license": "MIT",
@@ -13,25 +13,25 @@
   "exports": {
     ".": "./index.js",
     "./driver": "./driver.js",
-    "./register": "./register.js",
-    "./bun-preload": "./bun-preload.js",
-    "./transform": "./transform.js",
-    "./package.json": "./package.json"
+    "./package.json": "./package.json",
+    "./merge": "./merge.js"
   },
   "files": [
-    "index.js",
     "driver.js",
-    "register.js",
-    "bun-preload.js",
-    "transform.js",
-    "internal"
+    "index.js",
+    "internal",
+    "merge.js"
   ],
   "dependencies": {
     "@mdx-js/rollup": "^3.1.1",
+    "@shikijs/rehype": "^3.23.0",
+    "@uniflowed/host": "0.0.0-alpha.11",
+    "@uniflowed/server": "0.0.0-alpha.11",
     "rehype-slug": "^6.0.0",
     "remark-frontmatter": "^5.0.0",
     "remark-gfm": "^4.0.1",
     "remark-mdx-frontmatter": "^5.2.0",
+    "shiki": "^3.23.0",
     "vite": "^8.2.2"
   },
   "peerDependencies": {

package/bun-preload.js

@@ -1,22 +0,0 @@
-// Plain JavaScript: this file registers the loader, so it cannot need one.
-//
-// `bun --preload @uniflowed/vite/bun-preload app.js` runs a Flow project on
-// Bun without a build step, through Bun's own plugin API: every module uf is
-// responsible for is transformed by `uf transform` as Bun loads it. It is the
-// Bun counterpart of `./register.js`, and the policy of which files count is
-// the same `isFlowModule`.
-
-import { isFlowModule, transformFlow } from "./transform.js";
-
-Bun.plugin({
-  name: "uniflowed-flow",
-  setup(build) {
-    build.onLoad({ filter: /\.(js|jsx|mjs)$/ }, async (args) => {
-      if (!isFlowModule(args.path)) return undefined;
-      const source = await Bun.file(args.path).text();
-      const out = await transformFlow(source, args.path, { development: true, sourceMap: false });
-      if (out == null) return undefined;
-      return { contents: out.code, loader: "js" };
-    });
-  },
-});