@bakery-framework/core 2.0.0-alpha.5 → 2.0.0-alpha.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bakery-framework/core",
-  "version": "2.0.0-alpha.5",
+  "version": "2.0.0-alpha.7",
   "description": "Bakery framework core: handlers, router, config, session, caches, logger, compiler.",
   "keywords": [
     "bakery",

package/src/core/index.ts

@@ -4,6 +4,10 @@ import { Case, is, Math2, match, Try } from '../utils/common'
 import { encodeSSE, response, sse } from '../utils/http'
 import Bakery, { getHostname, hostKey, hostStore } from './bakery'
 import { getConfig, NOOP } from './config'
+// `./context` is already in this barrel's graph — line 5 reaches it through
+// `./bakery`, which re-exports `hostStore` from exactly here — so naming it
+// adds no module edge, only a name.
+import { getFrameworkVersion } from './context'
 import { createElement, Fragment, html } from './jsx'
 
 export const defineConfig = <T extends AppConfig>(config: T): T => config
@@ -63,6 +67,19 @@ export {
   encodeSSE,
   Fragment,
   getConfig,
+  /**
+   * The version of `@bakery-framework/core` itself, read from its own manifest.
+   *
+   * **Not the app's version**, which is what `import.meta.env.BAKERY_VERSION`
+   * and `getAppVersion()` report — the compiler reads those from
+   * `<cwd>/package.json`, so in an application they answer with the
+   * application's number. The name is a long-standing misnomer and this is the
+   * one that means what "Bakery version" sounds like it means.
+   *
+   * Exported because a plugin rendering framework chrome has no other way to
+   * ask. The dashboard's footer showed a hardcoded `v3` for want of it.
+   */
+  getFrameworkVersion,
   // Multi-host helpers. Documented in docs/configuration/multi-host.md, and
   // the only reason `./core/bakery` had to be a subpath of its own.
   getHostname,

package/src/handlers/core/$registry.ts

@@ -30,11 +30,16 @@ export class HandlerMap<T extends typeof Handler = typeof Handler> extends Map<
     }
   }
 
-  set(handlerClass: any, priority: number = 10): this {
-    super.set(handlerClass, priority)
+  /** Drop the derived views. Every mutation has to call this, not just `set`. */
+  private invalidate(): void {
     this.cachedList = null
     this.cachedGates = null
     this.cachedOrder = null
+  }
+
+  set(handlerClass: any, priority: number = 10): this {
+    super.set(handlerClass, priority)
+    this.invalidate()
     return this
   }
 
@@ -42,6 +47,30 @@ export class HandlerMap<T extends typeof Handler = typeof Handler> extends Map<
     return this.set(handlerClass, priority)
   }
 
+  /**
+   * `delete` and `clear` invalidate too, and neither used to.
+   *
+   * `list()` memoizes the sorted handler array and only `set` cleared it, so a
+   * removed handler stayed in the list — and therefore stayed *in the request
+   * pipeline* — until something happened to add one. Registration is
+   * add-only in a served process, which is why this never bit: it is reachable
+   * only by code that unregisters, and the first thing to do that was a test.
+   *
+   * A cache that survives the removal of its input is wrong regardless of who
+   * currently calls it, and "nothing removes handlers today" is a property of
+   * the callers rather than of this class.
+   */
+  override delete(handlerClass: any): boolean {
+    const removed = super.delete(handlerClass)
+    if (removed) this.invalidate()
+    return removed
+  }
+
+  override clear(): void {
+    super.clear()
+    this.invalidate()
+  }
+
   list(): T[] {
     if (this.cachedList) {
       return this.cachedList