@dunx/dashboard 2.4.0 → 3.0.0

package/README.md

@@ -1,242 +1,79 @@
 # @dunx/dashboard
 
-One page over a running dunx app: the routes it serves, the container it built,
-the gateways it upgrades, Redis, the config keys and the process itself - **with
-bull-board mounted for the queues**. Opt in with one module and one `app.use`.
+One page over a running [dunx](https://github.com/petarzarkov/dunx) app: the
+routes it serves, the container it built, the gateways it upgrades, Redis, the
+config keys and the process itself, **with bull-board mounted for the queues**.
+
+Every panel reads data dunx already computes, so the page is cheap.
+
+## Install
 
 ```bash
 bun add @dunx/dashboard
+# for the queues page
+bun add @bull-board/api @bull-board/ui @bull-board/bun
 ```
 
-An operator looking at a running dunx service has had three surfaces over the same
-data and none of them the one they wanted. `/docs` answers "what can a client
-call". `@dunx/mcp` answers the same questions for an agent, over stdio. Nothing
-answered **"what is this process actually doing"**. This is that page, and it is
-cheap because every panel reads data dunx already computes.
-
-## Mount it
+## Usage
 
 ```ts
 import { DashboardMiddleware, DashboardModule } from '@dunx/dashboard';
-import { JobPublisher, QueueModule } from '@dunx/infra/queue';
-import { RedisConnection, RedisModule } from '@dunx/infra/redis';
+import { JobPublisher } from '@dunx/infra/queue';
+import { RedisConnection } from '@dunx/infra/redis';
 
 @Module({
   imports: [
     DashboardModule.forRootAsync({
-      // This dynamic module is its own scope, so whatever exports the tokens the
-      // factory injects goes here.
-      imports: [QueueModule, RedisModule],
+      imports: [JobsModule, CacheModule],
+      inject: [JobPublisher, RedisConnection],
       useFactory: (queues: JobPublisher, redis: RedisConnection) => ({
+        path: '/api/_dunx',
         queues,
         redis,
-        authorize: (req) => req.headers.get('x-ops-key') === process.env.OPS_KEY,
+        authorize: (req) => isOperator(req),
       }),
-      inject: [JobPublisher, RedisConnection] as const,
     }),
   ],
 })
-export class AppModule {}
-```
+export class OpsModule {}
 
-```ts
 const app = await HttpFactory.create(AppModule);
-app.use(DashboardMiddleware, SessionGuard); // the dashboard first - see below
-await app.listen(3000);
-```
-
-That is the whole wiring. `JobPublisher` and `RedisConnection` are accepted **as
-they are**: this package restates what it needs from them structurally and depends
-on `@dunx/infra`, `bullmq` and `ioredis` not at all, so an app with no queues does
-not install a queue library to look at its routes.
-
-## Six panels
-
-| Panel                   | Reads                                                                              | Lifetime |
-| ----------------------- | ---------------------------------------------------------------------------------- | -------- |
-| **Overview**            | counts, uptime, heap, Bun version, dependency probes                              | polled   |
-| **Routes**              | `routesOf` - method, path, controller, module, guards, `@Roles`/`@Public`, schemas | static   |
-| **Gateways**            | `gatewaysOf` - upgrade path, the event each handler claims                         | static   |
-| **Modules & providers** | `providersOf`, `modulesOf` - what each module binds, exports and injects           | static   |
-| **Queues & Redis**      | queue names and a link to **bull-board**; Redis `PING` and `INFO`                 | polled   |
-| **Configuration**       | keys and types, values only where you allow them                                   | static   |
-
-The provider panel is the one that earns its place fastest. A missing-binding error
-names one token; reconstructing which module bound what and why the graph did not
-close is otherwise a grep across every `@Module`. An **unresolvable constructor
-parameter** - an interface, a primitive, a union, a type-only import - is called out
-in red on the overview, because each one is a boot error waiting to happen.
-
-The static panels use the same readers `@dunx/mcp` answers with, and they construct
-nothing. That is the deliberate inversion of MCP's rule: MCP refuses runtime
-questions because booting an app to answer them would open databases and bind
-sockets, and this package is *already inside* a booted app, so the reason does not
-apply. Stating it per panel is what stops the dashboard growing a `boot()`.
-
-## Every panel has a JSON sibling
-
-```bash
-curl -H 'x-ops-key: …' $APP/_dunx/api/snapshot
-curl -H 'x-ops-key: …' $APP/_dunx/api/runtime
-curl -H 'x-ops-key: …' $APP/_dunx/api/redis
-curl -H 'x-ops-key: …' $APP/_dunx/api/queues     # names only; the board is at /_dunx/queues
-```
-
-These are the endpoints the page itself uses, and they are supported rather than an
-implementation detail, which makes the dashboard usable on a box with no
-browser. Their types are exported (`Snapshot`, `RuntimeReport`, `RedisReport`,
-`QueuesReport`), so a `fetch` of them is typed. Anything *about* a queue is
-bull-board's own API, under `{path}/queues`.
-
-## Security
-
-**`authorize` has no default. Leaving it out serves the page to anyone who can
-reach the port**, and the page is routes plus config plus the provider graph on one
-screen - a reconnaissance gift. Omitting it logs a warning naming the mount at boot,
-because "fine behind a private network" is a real answer and guessing is not.
-
-Four things follow, and none is obvious:
-
-- **A rejected request gets 404 rather than 403.** A dashboard that announces itself to an
-  unauthenticated caller has told them where to keep knocking.
-- **Register it ahead of any session guard.** With the middleware last in the chain,
-  a `SessionGuard` answers every dashboard request `401` before `authorize` runs,
-  which defeats the 404 contract entirely.
-- **So `authorize` must be self-sufficient.** It receives the raw `Request` and runs
-  before anything has written an `AuthContext` - ask your auth library directly.
-- **`commands: false`** puts bull-board in its own read-only mode. Everything else
-  on the page only ever reports, so this is entirely about the queues. `authorize`
-  gates who reaches the mount; this gates what they can do once there.
-
-### Configuration is redacted by default
-
-`ConfigService` holds whatever your `validate` returned, which includes every secret
-you have. A deny-list of the usual suspects - `SECRET`, `PASSWORD`, `TOKEN` - looks
-careful and leaks the first key nobody thought of, so **the default reveals
-nothing**: the panel shows keys and types, which is most of what it is wanted for,
-and a value appears only where you say so.
-
-```ts
-config: appConfig,           // ConfigService satisfies this as written
-reveal: (key) => key === 'NODE_ENV' || key.startsWith('PUBLIC_'),
-```
-
-There is no "reveal" control on the page. Redaction is decided at boot by the app,
-not per click by whoever reached it.
-
-## The queues are bull-board's
-
-**dunx renders no queue UI.** `{path}/queues` is
-[bull-board](https://github.com/felixmosh/bull-board), mounted - flows, job logs,
-the repeatable-job editor, per-queue metrics, redis stats, retry/promote/clean, all
-of it, and none of it dunx's to maintain.
-
-This package briefly shipped its own queue table, and that was the wrong call
-under the framework's first rule: never invent what a mature library already
-solves.
-
-The one thing that had ever justified hand-rolling it was that mounting
-bull-board on `Bun.serve` meant writing a server adapter - which the deleted
-`@dunx/queue-dashboard` did, and which was a liability. **bull-board 8.6.0
-ships `@bull-board/bun`**, so that reason is gone and the integration is three
-calls.
-
-It also settled the question that started all this - see **Workers do show up**
-below. The hand-rolled panel had planned to omit a worker column and explain why;
-mounting bull-board asked the question honestly and exposed the real cause.
-
-```bash
-bun add @bull-board/api @bull-board/ui @bull-board/bun
-```
-
-All three are **optional peers**. Without them the queues panel says so and names
-the install line; nothing else on the page is affected.
-
-Two things dunx does contribute, and they are the two bull-board cannot know:
-
-- **It is behind the same `authorize`** as the rest of the mount, and answers the
-  same 404 to a caller that fails it.
-- **`commands: false` maps onto bull-board's own `readOnlyMode`** rather than dunx
-  refusing its POSTs. It already has the switch; a second implementation would
-  disagree the moment bull-board grew an operation dunx had not heard of.
-
-One caveat: **bull-board's page loads a webfont from Google Fonts.**
-dunx's own page fetches nothing, and that guarantee does not extend across the
-handoff.
-
-### Naming a queue this process only consumes
-
-A queue is a key prefix opened on first use, so `JobPublisher.opened` lists only what
-this process has **published** to. A worker that drains `thumbnails` and publishes
-nothing has opened nothing, and the queue would be invisible on the page that exists
-to show it:
-
-```ts
-queueNames: ['thumbnails'],
+app.use(DashboardMiddleware); // first, ahead of any session guard
 ```
 
-This is free. The board - and therefore any connection to the broker - is built on
-the **first request for `{path}/queues`**, never at boot and never by the polling
-`/api/queues` endpoint, which reads names straight off the options. An app that
-mounts the dashboard and never opens the board holds no socket for it, which
-lets a process still exit cleanly against an absent Redis.
-
-## Options
-
-| Option            | Default    | Notes                                                          |
-| ----------------- | ---------- | -------------------------------------------------------------- |
-| `path`            | `/_dunx`   | **`setGlobalPrefix` does not move it** - see below             |
-| `authorize`       | *none*     | No default. See Security                                       |
-| `title`           | `'dunx'`   | Header and `<title>`                                            |
-| `queues`          | *none*     | `JobPublisher`                                                  |
-| `queueNames`      | `[]`       | Queues this process only consumes                              |
-| `redis`           | *none*     | `RedisConnection`                                               |
-| `config`          | *none*     | `ConfigService`. Absent means no config panel                  |
-| `reveal`          | reveal none| Per-key opt in                                                 |
-| `probes`          | `[]`       | Anything else worth a light                                    |
-| `openApiPath`     | *none*     | Links each route row into the explorer                         |
-| `pollMs`          | `5000`     | `0` turns polling off and leaves the refresh button            |
-| `probeTimeoutMs`  | `2000`     | A hung probe costs one light, not the page                     |
-| `commands`        | `true`     | `false` → bull-board's own `readOnlyMode`                      |
-
-`app.setGlobalPrefix('api')` prefixes routes discovered from controllers. The
-dashboard is a **middleware matching a path**, not one of those - which is exactly
-what lets it serve a route table handed over at runtime without generating a
-controller per panel. With a global prefix, say so:
+## The panels
 
-```ts
-path: '/api/_dunx',
-```
+Six panels, each with a JSON sibling under `{path}/api/*`, so `curl` is a real
+way to read this on a box with no browser. The queues page is bull-board's.
 
-## Probes
+| Panel     | Shows                                                      |
+| --------- | ------------------------------------------------------------ |
+| Routes    | Every route, its guards and metadata, linked to `/docs`     |
+| Providers | The container graph, by module                              |
+| Gateways  | Every WebSocket gateway and its events                      |
+| Redis     | Connection state and `INFO`                                 |
+| Config    | Keys always, values only where `reveal` says so             |
+| Runtime   | The process, its memory and its probes                      |
 
-Anything with a name and a `check()`. It is awaited with a timeout and never allowed
-to throw into a response, so a hung dependency costs one light rather than the page -
-and a probe that did not answer reads `unknown`, never `down`, because those are
-different facts and one of them sends somebody to restart a healthy service.
+## Three things that are decisions
 
-```ts
-probes: [
-  {
-    name: 'database',
-    check: async () => {
-      await db.execute(sql`select 1`);
-      return { state: 'up', detail: 'sqlite' };
-    },
-  },
-],
-```
+- **`authorize` has no default**, and leaving it out serves the page to anyone
+  who can reach the port. Omitting it logs a warning naming the mount at boot.
+- **A rejected request gets 404, not 403.** Register the middleware **ahead of
+  any session guard**: a guard running first answers 401 and tells a prober the
+  mount exists. `authorize` takes the raw `Request` so it can be self-sufficient.
+- **Config values are redacted by default.** `reveal` is an opt-in allow-list; a
+  deny-list of the usual suspects leaks the first key nobody thought of.
 
-Passing `redis` adds one automatically, on `PING` rather than the connected flag: a
-flag says a socket is up and a round trip says the server is answering.
+## Notes
 
-## The page
+- It depends on `@dunx/infra` and `bullmq` not at all. `QueueSource` and
+  `RedisProbe` restate structurally what `JobPublisher` and `RedisConnection`
+  already are, so `queues: publisher` is the whole wiring.
+- The board is built on the first request for the queues page, never at boot, so
+  an app that never opens it holds no broker socket.
+- `commands: false` maps onto bull-board's own `readOnlyMode`.
 
-Server-rendered shell, React + Mantine inside it, **inlined** - no CDN, no `src=`,
-no `<link>`, so it opens on a host with no egress. It shares its theme and
-components with the dunx documentation site and the API explorer, so the three look
-like one product.
+## License
 
-The bundle sits behind `@dunx/dashboard/ui` and is reached with `await import()` on
-the first request for the page, so an app that mounts the module and never opens it
-pays nothing at boot. It is built by `internal/dashboard-ui`.
+MIT

package/dist/api/bounded.d.ts

@@ -1,14 +1,10 @@
 /**
- * Every read the dashboard makes off-process is bounded, and this is the one
- * implementation of that.
+ * Every read the dashboard makes off-process is bounded here. With Redis
+ * unreachable, `getJobCounts` waits out the 5 s connection timeout, so opening the
+ * dashboard on a broken broker hung the page for as long as the thing you opened
+ * it to look at was broken.
  *
- * The failure it exists for is specific and was measured: with Redis unreachable,
- * a queue's `getJobCounts` waits out the connection timeout - 5 s by default in
- * `@dunx/infra/queue` - so opening the dashboard on a broken broker hung the page
- * for exactly as long as the thing you opened it to look at was broken. A
- * dependency being down must cost one panel, not the page.
- *
- * The fallback is a **value**, not a rejection: a queue that could not be reached
- * still gets a row saying so, which is the whole point of looking.
+ * The fallback is a value rather than a rejection: an unreachable queue still gets
+ * a row saying so.
  */
 export declare const bounded: <T>(work: () => Promise<T>, ms: number, onTimeout: () => T) => Promise<T>;

package/dist/api/types.d.ts

@@ -1,5 +1,5 @@
 import type { ModuleNode, ProviderNode } from '@dunx/core';
-import type { GatewayNode, RouteNode } from '@dunx/http';
+import type { GatewayNode, RouteNode } from '@dunx/http/internal';
 import type { ProbeState } from '../contracts.js';
 /**
  * Everything the page reads, declared once.

package/dist/board.d.ts

@@ -18,12 +18,9 @@ export interface Board {
  * socket for it.
  */
 /**
- * The names alone, answerable **without opening anything**.
- *
- * That separation is the whole reason `/_dunx/api/queues` and `/_dunx/queues` are
- * different endpoints: the page asks this one on every poll to decide whether to
- * offer the link, and it must not open a socket to answer. Only somebody actually
- * opening the board does that.
+ * The names alone, answerable without opening anything - which is why
+ * `/_dunx/api/queues` and `/_dunx/queues` are different endpoints. The page polls
+ * this one to decide whether to offer the link, and must not open a socket for it.
  */
 export declare const boardNames: (options: DashboardOptions) => {
     readonly names: readonly string[];

package/dist/{chunk-xps6r8jv.js → chunk-66xm1dzm.js}

@@ -72,7 +72,7 @@ var __require = import.meta.require;
 
 // src/api/snapshot.ts
 import { modulesOf, providersOf } from "@dunx/core";
-import { gatewaysOf, isGateway, routesOf } from "@dunx/http";
+import { gatewaysOf, isGateway, routesOf } from "@dunx/http/internal";
 var typeOf = (value) => {
   if (value === null)
     return "null";
@@ -102,6 +102,3 @@ var snapshotOf = (root, options) => ({
 });
 
 export { __decoratorStart, __decoratorMetadata, __runInitializers, __decorateElement, __require, metaOf, snapshotOf };
-
-//# debugId=D21070FBD0B8DA7064756E2164756E21
-//# sourceMappingURL=chunk-xps6r8jv.js.map

package/dist/contracts.d.ts

@@ -1,74 +1,38 @@
 /**
- * What the dashboard needs from the things it reports on, restated structurally.
- *
- * **This package depends on `@dunx/infra` not at all**, and on `bullmq` not at
- * all - the same choice `@dunx/auth` makes with `DrizzleSource` and `RedisStore`.
- * A dashboard that peer-depended on the queue library would oblige an app with no
- * queues to install it to see its routes, and would put a build-order edge between
- * two packages that never call each other.
- *
- * This list used to be twice as long. `DashboardQueue` and `DashboardJob` restated
- * bullmq's `Queue` and `Job` in enough detail to drive a queue table - signatures
- * shaped to satisfy bullmq's own variance, with a paragraph explaining why. All of
- * it went when bull-board took the queue UI back: the queue object is now passed
- * straight through to `BullMQAdapter`, so there is nothing left to describe.
- *
- * Everything here is satisfied by an object an app already has:
- *
- * | This             | Satisfied by                             |
- * | ---------------- | ---------------------------------------- |
- * | `QueueSource`    | `JobPublisher` from `@dunx/infra/queue`    |
- * | `RedisProbe`     | `RedisConnection` from `@dunx/infra/redis` |
- * | `ConfigValues`   | `ConfigService` from `@dunx/core`          |
- *
- * No adapter, no wrapper - `queues: publisher` in the options is the whole wiring,
- * which is what makes the restatement worth its lines rather than a tax.
+ * What the dashboard needs from the things it reports on, restated structurally
+ * so this package depends on `@dunx/infra` and `bullmq` not at all. Each is
+ * satisfied by an object an app already has:
+ *
+ * | This           | Satisfied by                               |
+ * | -------------- | ------------------------------------------ |
+ * | `QueueSource`  | `JobPublisher` from `@dunx/infra/queue`    |
+ * | `RedisProbe`   | `RedisConnection` from `@dunx/infra/redis` |
+ * | `ConfigValues` | `ConfigService` from `@dunx/core`          |
  */
 /**
- * The validated configuration. `ConfigService` satisfies it as written.
- *
- * Passed in rather than resolved from the container, and that is deliberate twice
- * over. Mechanically, `inject()` only works inside a class the container builds and
- * this middleware is built by a factory. But the better reason is that showing an
- * app's configuration should be something the app **says yes to** - the same
- * instinct behind `reveal` defaulting to revealing nothing.
+ * The validated configuration. `ConfigService` satisfies it as written. Passed in
+ * rather than resolved, so showing an app's configuration is something the app
+ * says yes to.
  */
 export interface ConfigValues {
-    /**
-     * `object`, not `Record<string, unknown>`: an app's `AppConfig` is an interface
-     * with no index signature, so the record type would reject the very
-     * `ConfigService` this exists to accept. It is enumerated, never read by a key
-     * this package knows.
-     */
+    /** `object` rather than `Record<string, unknown>`: an app's `AppConfig` has no
+     * index signature, so the record type would reject it. */
     readonly values: object;
 }
 /**
- * Where queues come from. `JobPublisher` satisfies it as written.
- *
- * `opened` is what the publisher has opened *so far*, which is deliberately not the
- * same as "every queue this app has" - a queue is a key prefix opened on first use,
- * so a web process that has published to none has opened none. That is why
- * `DashboardOptions.queueNames` exists: a process that consumes a queue it never
- * publishes to has to name it, and the panel says which of the two it is showing.
+ * Where queues come from. `JobPublisher` satisfies it as written. `opened` is what
+ * the publisher has opened so far, not every queue the app has - which is why
+ * `DashboardOptions.queueNames` exists for a consume-only process.
  */
 export interface QueueSource {
     readonly opened: readonly string[];
-    /**
-     * bullmq's `Queue`, handed to bull-board's `BullMQAdapter` untouched - which is
-     * why the return type is `unknown` rather than a restatement. dunx reads nothing
-     * off it and calls nothing on it; matching bullmq's own signatures here was a
-     * whole file of variance notes existing only to describe a UI dunx no longer
-     * renders.
-     */
+    /** bullmq's `Queue`, handed to `BullMQAdapter` untouched, so the return type is
+     * `unknown` rather than a restatement. */
     queue(name: string): unknown;
 }
 /**
- * Enough Redis to answer "is it up and what is it doing". `RedisConnection`
- * satisfies it, and so does `Bun.RedisClient` with a `send`.
- *
- * `send` rather than a typed `info()`: `INFO` is one command whose reply is a text
- * blob, and adding a method per Redis command to a restatement is how a
- * restatement becomes a client library.
+ * Enough Redis to answer "is it up and what is it doing". `send` rather than a
+ * typed `info()`: a method per command is how a restatement becomes a client.
  */
 export interface RedisProbe {
     readonly connected: boolean;
@@ -76,25 +40,15 @@ export interface RedisProbe {
     send(command: string, args?: readonly string[]): Promise<unknown>;
 }
 /**
- * The state a probe reports, and its result. `unknown` is not `down`; see
- * `StatusDot`.
- *
- * Declared in `@dunx/http` and re-exported here. They moved down when the health
- * module became a second consumer: this package already peer-depends on
- * `@dunx/http`, so the descent adds no edge, and two copies of a three-value union
- * is how one of them gains a fourth value nobody else honours.
- *
- * `RedisProbe` below did **not** move with them. `@dunx/http`'s `PingProbe` is a
- * `ping` and nothing else, while this needs `connected` and `send` for the `INFO`
- * panel, so one shared contract would oblige a health check to supply two members
- * it never calls.
+ * The state a probe reports, and its result. `unknown` is not `down`. Declared in
+ * `@dunx/http` and re-exported here, since this package already peer-depends on
+ * it. `RedisProbe` below did not move with them: `PingProbe` is a `ping` alone.
  */
 export type { ProbeResult, ProbeState } from '@dunx/http';
 import type { ProbeResult } from '@dunx/http';
 /**
- * Anything else worth a light on the page - a third-party API, a disk, a leader
- * election. The dashboard awaits it with a timeout and never lets it throw into a
- * response, so a probe that hangs costs one panel rather than the page.
+ * Anything else worth a light on the page. Awaited with a timeout and never let
+ * to throw, so a probe that hangs costs one panel rather than the page.
  */
 export interface DashboardProbe {
     readonly name: string;

package/dist/index.js

@@ -6,7 +6,7 @@ import {
   __require,
   __runInitializers,
   snapshotOf
-} from "./chunk-xps6r8jv.js";
+} from "./chunk-66xm1dzm.js";
 
 // src/module.ts
 import {
@@ -167,9 +167,7 @@ class DashboardOptions {
     this.commands = init.commands ?? true;
   }
 }
-Object.defineProperty(DashboardOptions, Symbol.for("dunx.deps"), {
-  value: () => [{ unresolved: "init: DashboardOptionsInit = {}" }]
-});
+Object.defineProperty(DashboardOptions, Symbol.for("dunx.deps"), { value: () => [{ unresolved: "init: DashboardOptionsInit = {}", optional: true }] });
 var normalizeMount = (path) => {
   const trimmed = `/${path.split("/").filter(Boolean).join("/")}`;
   if (trimmed === "/") {
@@ -416,9 +414,7 @@ class DashboardMiddleware {
     return this.#page;
   }
 }
-Object.defineProperty(DashboardMiddleware, Symbol.for("dunx.deps"), {
-  value: () => [DashboardOptions, { unresolved: "root: ModuleRef", typeOnly: "ModuleRef" }, Logger]
-});
+Object.defineProperty(DashboardMiddleware, Symbol.for("dunx.deps"), { value: () => [DashboardOptions, { unresolved: "root: ModuleRef", typeOnly: "ModuleRef" }, Logger] });
 
 // src/module.ts
 var middleware = () => provide(DashboardMiddleware, {
@@ -470,6 +466,3 @@ export {
   handleDashboard,
   normalizeMount
 };
-
-//# debugId=CFA504A7E130188D64756E2164756E21
-//# sourceMappingURL=index.js.map

package/dist/middleware.d.ts

@@ -3,27 +3,16 @@ import type { Middleware, Next, RouteContext } from '@dunx/http';
 import type { BunRequest } from 'bun';
 import { DashboardOptions } from './options.js';
 /**
- * A **global middleware**, not a controller, and that is not a stylistic choice.
+ * A global middleware rather than a controller: `app.use` runs in front of the
+ * unmatched-path fallback, which is where the dashboard's paths land because the
+ * app declares none of them.
  *
- * Middleware registered with `app.use` runs in front of the unmatched-path
- * fallback, which is exactly where the dashboard's paths land because the app
- * declares none of them. Declaring them as dunx routes would mean generating
- * controllers for a route table handed over at runtime, and every panel would need
- * its own `@Get`.
+ * Register it ahead of any session guard - with this last in the chain a guard
+ * answers `401` before `authorize` runs, defeating the 404 contract. That works
+ * only because `authorize` gets the raw `Request`, so keep it self-sufficient.
+ * Anything outside the mount falls through untouched.
  *
- * Two consequences of that, both learned the hard way and both worth keeping:
- *
- * - **Register it ahead of any session guard.** Measured in `dunx-template`: with
- *   this last in the chain, `SessionGuard` answered every dashboard request `401`
- *   before `authorize` ran, which defeats the 404 contract entirely. That works
- *   only because `authorize` gets the raw `Request` and can ask the auth library
- *   itself, so keep it self-sufficient.
- * - **Anything outside the mount falls through untouched**, so the app's own
- *   routes and its 404 behave exactly as before.
- *
- * The page bundle is built on the **first request** and memoised on the promise,
- * so two concurrent first requests build one page and importing this package pulls
- * in none of its 400-odd KB.
+ * The page bundle is built on the first request and memoised on the promise.
  */
 export declare class DashboardMiddleware implements Middleware {
     #private;

package/dist/module.d.ts

@@ -1,17 +1,12 @@
 import { type AsyncModuleConfig, type Deps, type DynamicModule } from '@dunx/core';
 import { type DashboardOptionsInit } from './options.js';
 /**
- * Binds the options and the middleware. **It does not register the middleware** -
- * the app does, with `app.use(DashboardMiddleware)`, and that is deliberate:
- * position in the chain is the whole security property here.
+ * Binds the options and the middleware, and does not register it - the app does,
+ * because position in the chain is the security property here.
  *
- * `@Module({ middleware })` scopes middleware to that module's own controllers, of
- * which this module has none, so it would never run. Registering globally from
- * inside the module would put it wherever the module happened to be imported, and
- * it has to be **ahead of any session guard** - measured in `dunx-template`, where a
- * guard running first answered every dashboard request `401` before `authorize`
- * ran, defeating the 404 contract. Two lines in the app, one of which is a
- * decision:
+ * `@Module({ middleware })` scopes to that module's own controllers, of which this
+ * has none. Registering globally from inside would put it wherever the module was
+ * imported, and it has to sit ahead of any session guard:
  *
  * ```ts
  * const app = await HttpFactory.create(AppModule);