@dunx/create-app 1.2.0 → 1.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dunx/create-app",
-  "version": "1.2.0",
+  "version": "1.3.0",
   "description": "Scaffold a new dunx application - bunx @dunx/create-app my-api",
   "keywords": [
     "bun",

package/templates/features/docs/docs.demo.ts

@@ -80,9 +80,14 @@ export class DocsDemo {
     // markup, with both script bodies removed. Inside a <script> everything is
     // text, and minified React's own string table contains `src=` and `<script`.
     const shell = html.replace(/(<script[^>]*>)[\s\S]*?(<\/script>)/g, '$1$2');
+    // A `<link>` counts only if it would actually fetch. The page carries one
+    // for its favicon, as a `data:` URI, which the browser never requests.
+    const fetchedLink = [...shell.matchAll(/<link\b[^>]*href="([^"]*)"/g)].some(
+      ([, href]) => href !== undefined && !href.startsWith('data:'),
+    );
     const external =
       /\ssrc=/.test(shell) ||
-      /<link\b/.test(shell) ||
+      fetchedLink ||
       /url\(\s*["']?(https?:)?\/\//.test(html) ||
       html.includes('//cdn');
     logger.info(

package/templates/features/jobs/jobs.controller.ts

@@ -26,7 +26,7 @@ const oneJob = { params: z.object({ id: z.string().min(1) }) } as const;
 /**
  * The publish side. Nothing here consumes: `QueueModule.forRoot` binds
  * `JobPublisher` and no worker, so this process enqueues and returns immediately.
- * Run `bun run worker` to consume.
+ * Consumed by this same process - see `JobsModule`'s `consume: true`.
  */
 @Controller('jobs')
 export class JobsController {

package/templates/features/jobs/jobs.module.ts

@@ -10,10 +10,13 @@ import { ThumbnailJobs } from './thumbnail.jobs.js';
  * process publishes, a separate worker process consumes, and they agree only on
  * this module.
  *
- * `QueueModule.forRoot` binds the publish side alone, so importing it does not
- * open a worker - a web process that publishes never consumes by accident.
+ * `consume: true` is what makes this process work them as well as publish, and it
+ * is the only line about it anywhere - the container owns starting and stopping the
+ * workers, so no entrypoint has to. Leave it out and the module binds the publish
+ * side alone, which is what a web tier with a separate worker fleet wants.
+ *
  * `PicturesModule` is here because the handler injects `Thumbnails`, and the
- * worker's container has to be able to build it.
+ * container that runs it has to be able to build it.
  */
 @Module({
   imports: [
@@ -23,6 +26,13 @@ import { ThumbnailJobs } from './thumbnail.jobs.js';
         return {
           ...(url === undefined ? {} : { url }),
           prefix: 'dunx-full',
+          // This process works its own queues. The container starts the workers at
+          // onInit and stops them at onShutdown - before the database they use -
+          // so `main.ts` says nothing about queues and there is no second command.
+          consume: true,
+          // The file bullmq forks into for a queue whose handler is marked
+          // `background`. Absolute, because the child resolves it, not this module.
+          processor: new URL('./jobs.processor.ts', import.meta.url).pathname,
         };
       },
       inject: [AppConfigService] as const,

package/templates/features/jobs/jobs.processor.ts

@@ -0,0 +1,37 @@
+import { JobProcessor } from '@dunx/infra/queue';
+import { ConfigModule, Module } from '@dunx/core';
+import { LoggerModule } from '@dunx/infra/logger';
+import { AppConfigService, validate } from '../config.js';
+import { JobsModule } from './jobs.module.js';
+
+/**
+ * **The file bullmq forks into.** Its default export is the processor, and nothing
+ * else here runs in the parent.
+ *
+ * The child builds its own container, which is the whole point: a handler gets the
+ * database, the image pipeline and the logger it declares, without sharing an event
+ * loop with the process serving HTTP. `JobProcessor` builds it once per child and
+ * reuses it for every job on that child.
+ *
+ * Its own module rather than reusing `WorkerModule` from `worker.ts`: that file is
+ * an entrypoint with a `run()` at the bottom, and importing it here would boot a
+ * second worker inside every child.
+ */
+@Module({
+  imports: [
+    ConfigModule.forRoot({ validate, as: AppConfigService }),
+    LoggerModule.forRootAsync({
+      useFactory: (config: AppConfigService) => ({
+        // Named so a line from a child is attributable to one on sight - which is
+        // the traceability a sandbox is for.
+        name: `${config.get('appName')}-job`,
+        level: config.get('log').level,
+      }),
+      inject: [AppConfigService] as const,
+    }),
+    JobsModule,
+  ],
+})
+class JobProcessorModule {}
+
+export default new JobProcessor(JobProcessorModule).handle;

package/templates/features/jobs/thumbnail.jobs.ts

@@ -32,7 +32,10 @@ export class ThumbnailJobs {
     private readonly logger: Logger,
   ) {}
 
-  @JobHandler({ queue: THUMBNAIL_QUEUE, name: 'render' })
+  // `background: true` puts this queue's jobs in a forked child: a slow or
+  // crashing render cannot take the server with it, and its log lines still land
+  // in this process's stream.
+  @JobHandler({ queue: THUMBNAIL_QUEUE, name: 'render', background: true })
   async render(job: Job<RenderRequest>): Promise<RenderResult> {
     const encoded = await this.thumbnails.render({
       width: job.data.width,
@@ -45,8 +48,7 @@ export class ThumbnailJobs {
       height: encoded.height,
       bytes: encoded.bytes.byteLength,
     };
-    // Written by the worker process, so seeing this line is how you know the job
-    // did not run in the web process.
+    // Written in the child, and visible here: that is the point of the sandbox.
     this.logger.info(`rendered job ${job.id ?? '?'}`, result);
     return result;
   }