@n6k.io/build 0.0.1 → 0.0.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@n6k.io/build",
-  "version": "0.0.1",
+  "version": "0.0.4",
   "private": false,
   "description": "Static build pipeline (.mdx + ts/tsx/js/jsx → esbuild bundle → HTML) for n6k apps",
   "homepage": "https://github.com/n6k-io/build#readme",
@@ -81,7 +81,7 @@
   },
   "devDependencies": {
     "@eslint/js": "^10.0.1",
-    "@n6k.io/db": "link:@n6k.io/db",
+    "@n6k.io/db": "^0.5.0",
     "@storybook/react": "^10.4.4",
     "@tanstack/react-query": "^5.101.0",
     "@types/bun": "latest",

package/src/n6k-workers.d.ts

@@ -0,0 +1,8 @@
+// Virtual module provided by the `bundleN6kWorkers` Vite plugin (src/vite/workers.ts).
+// Resolves to the DuckDB worker script URLs: stable `/_n6k/workers/*` paths in
+// dev, content-hashed `assets/*-[hash].js` URLs in a production/static build.
+declare module "virtual:n6k-workers" {
+  export const duckdbWorkerUrl: string;
+  export const fetchWorkerUrl: string;
+  export const wsWorkerUrl: string;
+}

package/src/storybook/story-shell.tsx

@@ -1,21 +1,34 @@
 import { useMemo, type ReactNode } from "react";
 import { DuckDBProvider } from "@n6k.io/db/react";
-import { N6K_DEFAULT_WORKER_URLS } from "@n6k.io/db/workers";
+import {
+  duckdbWorkerUrl,
+  fetchWorkerUrl,
+  wsWorkerUrl,
+} from "virtual:n6k-workers";
 import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
 
+// Worker URLs come from the `bundleN6kWorkers` Vite plugin's virtual module —
+// the same source the real app (v3's DuckDBProviderClient) uses. This is what
+// makes the workers actually ship: in a static build the plugin only emits the
+// content-hashed worker assets when `virtual:n6k-workers` is imported. The old
+// `N6K_DEFAULT_WORKER_URLS` resolved the canonical `/_n6k/workers/*` paths,
+// which exist only via the dev middleware — so a static Storybook (GitHub Pages)
+// 404'd on every worker. Dev still resolves those same stable paths here.
+const duckdbOptions = {
+  fetchWorkerUrl,
+  duckdbWorkerUrl,
+  wsWorkerUrl,
+};
+
 /**
  * The provider stack every n6k story needs: a fresh react-query client and a
- * DuckDB-WASM context. Worker URLs come straight from the driver's canonical
- * manifest (`N6K_DEFAULT_WORKER_URLS`) rather than being hardcoded, so they can
- * never drift from what the `bundleN6kWorkers` Vite middleware actually serves.
+ * DuckDB-WASM context.
  */
 export function StoryShell({ children }: { children: ReactNode }) {
   const queryClient = useMemo(() => new QueryClient(), []);
   return (
     <QueryClientProvider client={queryClient}>
-      <DuckDBProvider duckdbOptions={N6K_DEFAULT_WORKER_URLS}>
-        {children}
-      </DuckDBProvider>
+      <DuckDBProvider duckdbOptions={duckdbOptions}>{children}</DuckDBProvider>
     </QueryClientProvider>
   );
 }

package/src/util/logger.ts

@@ -11,31 +11,14 @@ export function initLogger(debug: boolean) {
   }
 }
 
-// pino does not expose its underlying stream in its public types, so narrow to
-// the one method we need (`end`) via a runtime type guard rather than a cast.
-function hasFlushableStream(
-  l: unknown,
-): l is { stream: { end: (cb: () => void) => void } } {
-  return (
-    typeof l === "object" &&
-    l !== null &&
-    "stream" in l &&
-    typeof l.stream === "object" &&
-    l.stream !== null &&
-    "end" in l.stream &&
-    typeof l.stream.end === "function"
-  );
-}
-
+// Drain pino's buffered logs before the process exits. pino keeps its output
+// stream on an internal Symbol (not a public `.stream` property), so there is
+// nothing to `.end()` directly — `logger.flush(cb)` is the supported drain: it
+// invokes the callback once the underlying stream (including the pino-pretty
+// worker thread) has flushed.
 export function flushLogger(): Promise<void> {
   return new Promise((resolve) => {
-    logger.flush(() => {
-      if (hasFlushableStream(logger)) {
-        logger.stream.end(() => resolve());
-      } else {
-        resolve();
-      }
-    });
+    logger.flush(() => resolve());
   });
 }