mir-backend-node-nestjslisted

Make It Right (NestJS module). NestJS + TypeScript specific reliability augmentation. Use alongside mir-backend and mir-backend-node when the target stack is NestJS — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: singleton DI scope bleeding request state across users, the full execution-order pipeline (middleware → guards → interceptors → pipes → handler → interceptors → exception filters), ValidationPipe with whitelist and forbidNonWhitelisted to stop mass assignment, and offloading durable work to a queue (Bull/BullMQ) rather than running it in a request. TRIGGER only when the Node backend stack is NestJS — building, reviewing, or debugging a NestJS controller, provider, guard, pipe, interceptor, or exception filter. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-node (V8 event-loop / process-model concerns: blocking, worker_threads, unhandled rejections, backpressure, timeouts); this module only adds NestJS library mechanics. SKIP for Express, F
anantbhandarkar/make-it-right · ★ 12 · API & Backend · score 83

Install: claude install-skill anantbhandarkar/make-it-right

# /mir-backend-node-nestjs · Make It Right (NestJS) Bottom tier of the chain: `mir-backend` (generic gates) → `mir-backend-node` (V8/Node event-loop model) → **this** (NestJS library mechanics). Run the gates first; load the Node runtime tier for event-loop and process-model concerns; reach for *this* at Gate 5 (design mechanics), Gate 6 (implementation), and Gate 7 review. **Runtime-level concerns (blocking the event loop, worker_threads, unhandled rejections, stream backpressure, AbortController timeouts, heap limits) live in `mir-backend-node` — not here.** **Stack assumed:** NestJS 10/11 on Node 20+ LTS with TypeScript strict mode. NestJS runs on Express by default; Fastify adapter noted where behavior differs. ## The NestJS footguns AI walks into most ### 1. Singleton scope stores request state — bleeds across users **All providers in NestJS are SINGLETON by default.** The same class instance handles every request for the lifetime of the application. Storing per-request data (current user, tenant ID, request ID, transaction handle) in a singleton service property is a race condition that bleeds one user's data into another's request under concurrent load — a serious security defect: ```ts // WRONG — singleton; currentUser is shared across all concurrent requests @Injectable() export class OrderService { private currentUser: User; // ← shared mutable state; data bleeds between requests async getOrders() { return this.db.findOrders({ userId: this.currentUser