@bakery-framework/plugin-dashboard 2.0.0-alpha.14 → 2.0.0-alpha.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bakery-framework/plugin-dashboard",
-  "version": "2.0.0-alpha.14",
+  "version": "2.0.0-alpha.16",
   "description": "Bakery dashboard plugin.",
   "keywords": [
     "bakery",
@@ -33,11 +33,11 @@
     "!src/tests"
   ],
   "dependencies": {
-    "@bakery-framework/core": "^2.0.0-alpha.14",
-    "@bakery-framework/plugin-analytics": "^2.0.0-alpha.14"
+    "@bakery-framework/core": "^2.0.0-alpha.16",
+    "@bakery-framework/plugin-analytics": "^2.0.0-alpha.16"
   },
   "devDependencies": {
-    "@bakery-framework/orm": "^2.0.0-alpha.14"
+    "@bakery-framework/orm": "^2.0.0-alpha.16"
   },
   "engines": {
     "bun": ">=1.4.0"

package/src/client/parts/logs.ts

@@ -77,12 +77,19 @@ export function initLogsWebSocket() {
     '<div style="color: var(--text-muted);">Connecting to server log stream...</div>'
 
   try {
-    logsWs = new WebSocket(getWebSocketUrl('/_livereload'))
+    // `/_dashboard/logs`, not `/_livereload`. The live-reload socket is
+    // registered only under `DEV`, so this panel answered 400 on every
+    // production server and sat on "Connecting..." for ever. The console has
+    // its own socket now, behind the console's own door.
+    logsWs = new WebSocket(getWebSocketUrl('/_dashboard/logs'))
 
     logsWs.onopen = () => {
       consoleEl.innerHTML =
         '<div style="color: var(--ok); display: flex; align-items: center; gap: 0.25rem;"><span>Connected to logs pipeline. Listening for events...</span></div>'
-      logsWs?.send(JSON.stringify({ type: 'subscribe_logger' }))
+      // No `subscribe_logger` frame: membership is the handler's `open`, so
+      // there is nothing to ask for. That message was `LiveReloadHandler`'s
+      // protocol, and it is what an app page still sends to forward its own
+      // console in development.
     }
 
     logsWs.onmessage = event => {

package/src/endpoints/logs-socket.ts

@@ -0,0 +1,72 @@
+import { WebSocketHandler } from '@bakery-framework/core/handlers'
+import { connectedLoggers } from '@bakery-framework/core/logger'
+import { isAnalyticsAuthorized } from '@bakery-framework/plugin-analytics/stats'
+import type { ServerWebSocket } from 'bun'
+
+/**
+ * The console's log stream.
+ *
+ * **The Logs panel was dead in production**, and only in production. Its client
+ * connected to `/_livereload`, which `LiveReloadHandler` serves — and that
+ * handler is registered only under `DEV` and refuses in `canHandle` besides.
+ * So a production server answered 400 on the upgrade, nothing ever joined
+ * `connectedLoggers`, and the panel sat on "Connecting to server log
+ * stream..." for the life of the process. Measured against `bun run serve`
+ * before this existed: `/_livereload` → 400, console → 200.
+ *
+ * Same shape as the bundle ETag bug and the timescale import before it: a dev
+ * server takes a different branch, so the thing works on the machine where it
+ * is written and nowhere else.
+ *
+ * **Not fixed by registering `LiveReloadHandler` in production.** That socket
+ * is the *watcher's*: it publishes `force_reload` to every subscriber and
+ * echoes `client_log` frames between browsers. Shipping it to production would
+ * be adding a surface, not repairing one. The console owns its own panel, so
+ * it owns its own socket, which is the same split analytics already has with
+ * `/_analytics_ws`.
+ *
+ * Membership is the only thing this does. Core owns the registry
+ * (`logger/clients.ts`) and the dashboard's `setLogCallback` does the
+ * broadcasting; in development `LiveReloadHandler` adds app pages to the same
+ * Set when they forward their console, which is why those lines show up here
+ * too.
+ */
+export class DashboardLogsHandler extends WebSocketHandler {
+  static override readonly namespace = '/_dashboard'
+
+  /**
+   * **The door is checked here because there is nowhere later.**
+   *
+   * `router.ts` attempts the upgrade before `onRoute`, before `onRequest` and
+   * before any fetch handler resolves, so a plugin hook cannot gate a socket.
+   * `AnalyticsWSHandler` carries the same note for the same reason.
+   *
+   * It is the console's own door: `isAnalyticsAuthorized` is what guards
+   * `/_dashboard` itself, so a stream of every server log line is admitted by
+   * exactly what admits the page that renders it. Anything weaker would hand
+   * out log lines to someone who cannot open the console.
+   *
+   * Async because `authorize` may be a predicate the application supplies; the
+   * registry awaits a promise-returning `canHandle`.
+   *
+   * The path sits inside `/_dashboard`, which `DashboardHandler` claims for
+   * *fetch* at priority 120. That is not a collision: the upgrade is dispatched
+   * from a separate registry and runs first, so the fetch handler never sees
+   * this request.
+   */
+  static override async canHandle(
+    path: string,
+    req?: Request,
+  ): Promise<boolean> {
+    if (path !== '/_dashboard/logs') return false
+    return req ? await isAnalyticsAuthorized(req) : false
+  }
+
+  static override open(ws: ServerWebSocket<any>) {
+    connectedLoggers.add(ws)
+  }
+
+  static override close(ws: ServerWebSocket<any>) {
+    connectedLoggers.delete(ws)
+  }
+}

package/src/setup.ts

@@ -31,6 +31,7 @@ import {
   handleGetSessions,
   handleUpdateSession,
 } from './endpoints/sessions'
+import { DashboardLogsHandler } from './endpoints/logs-socket'
 import { pluginPath } from './paths'
 import renderDashboardShell from './shell'
 
@@ -129,6 +130,12 @@ export function setupDashboard(
   // plugin's own directory — no bespoke asset route, no hand-rolled caching.
   mountRoutes('/_dashboard', pluginPath('../public'))
 
+  // The console's log stream, and it is registered in every mode. The Logs
+  // panel used to ride on `/_livereload`, which exists only under `DEV` — so
+  // the panel worked on the machine it was written on and answered 400
+  // everywhere else. See `endpoints/logs-socket.ts`.
+  Bakery.handlers.websocket.set(DashboardLogsHandler)
+
   Bakery.handlers.fetch.set(DashboardHandler, 120)
 }
 
@@ -140,7 +147,7 @@ async function handleDashboardView() {
 }
 
 /**
- * A bare `import` left in the bundle, or `null`.
+ * Why the bundle cannot run in a `<script>`, or `null`.
  *
  * `bundleModule` marks every *installed* package external, so a bare specifier
  * survives into the output and resolves through the page's import map. That is
@@ -149,19 +156,35 @@ async function handleDashboardView() {
  * apply to one, and a top-level `import` is a syntax error — so the *entire*
  * bundle fails to execute and the console does nothing at all.
  *
- * It is worth a check rather than a convention because of how it failed.
- * `Bun.build` reported success, the file was served with a 200 and the right
- * length, typecheck passed, and 2,376 tests passed — because nothing
- * *requested the page*. That is the same gap CLAUDE.md already records for
- * `apps/starter`: a process that boots is not a page that works.
+ * **This asks the engine instead of matching a pattern, and the first version
+ * of it matched a pattern and was wrong.** It anchored on `^import`. In
+ * development the bundle is not minified and the import starts a line, so it
+ * looked right. Production minifies, the import lands mid-line, and the check
+ * that existed to catch exactly this missed it — measured by reintroducing the
+ * bug and watching a production server answer 200 with the import present.
+ *
+ * Against seven shapes, the anchored regex was wrong on three: a minified bare
+ * import, a side-effect-only `import"./x.css"`, and a top-level `await`. A
+ * widened regex got the first two and still missed the third. `new Function`
+ * is wrong on none of them, because it is not approximating the question — a
+ * function body rejects a top-level `import` and a top-level `await` for the
+ * same reasons a classic script does. It also costs less than the widened
+ * regex: 13.0 us against 26.4 on a 24 KB bundle, and 12.0 for the broken one.
+ *
+ * It parses without executing, and only on the build path — the cached branch
+ * returns the file and never reaches here.
  *
- * Matched on a line starting with `import`, which is what an ESM bundle emits
- * for an external. A dynamic `import(...)` inside a function body is fine and
- * does not start a line.
+ * One known difference, and it is in the safe direction: a function body
+ * permits a top-level `return`, which a script does not. `Bun.build` does not
+ * emit one, and a false pass is a missed report rather than a broken page.
  */
-export function bareImportIn(bundle: string): string | null {
-  const match = bundle.match(/^import\s[^\n]*?from\s*['"]([^'"]+)['"]/m)
-  return match ? match[1]! : null
+export function whyUnrunnable(bundle: string): string | null {
+  try {
+    new Function(bundle)
+    return null
+  } catch (error) {
+    return (error as Error).message
+  }
 }
 
 /**
@@ -205,15 +228,15 @@ export async function handleJsAsset() {
     )
   }
 
-  // See `bareImportIn`. A build that "succeeded" and cannot run is worse than
+  // See `whyUnrunnable`. A build that "succeeded" and cannot run is worse than
   // one that failed, because it is silent.
-  const bare = bareImportIn(bundleResult.content as string)
-  if (bare) {
+  const unrunnable = whyUnrunnable(bundleResult.content as string)
+  if (unrunnable) {
     pluginLog.DASHBOARD_BUNDLE_ERR({
-      error: `dashboard.js kept a bare import of "${bare}". It is served as a classic script, so an import map cannot resolve it and the whole bundle fails to parse. The console client must not import across a package boundary.`,
+      error: `dashboard.js cannot run as a classic script: ${unrunnable}. The usual cause is an import across a package boundary, which the bundler leaves as a bare specifier for the import map — and an import map does not apply to a classic script.`,
     })
     return response.error(
-      `dashboard.js kept a bare import of "${bare}"`,
+      `dashboard.js cannot run as a classic script: ${unrunnable}`,
       500,
     )
   }