@lenne.tech/nest-server 11.42.5 → 11.42.6

package/docs/REQUEST-LIFECYCLE.md

@@ -569,7 +569,7 @@ Both use body-parser's default limit of **100 kB** unless `bodyParser` says othe
 bodyParser: { json: { limit: '2mb' } },
 ```
 
-`CoreBodyParserInitializer` applies it during module init by replacing the handle of the global parser layers NestJS created — in place, because NestJS registers them before any init hook runs and a parser appended later would sit behind the routes. Running during module init is what makes the limit hold under `Test.createTestingModule()`, which never runs `main.ts`. A path-scoped parser (`server.use('/upload', json({ limit }))` in `main.ts`) runs before the global one and is left untouched — that remains the way to give one path a different limit.
+`CoreBodyParserInitializer` applies it during module init by replacing the handle of the global parser layers NestJS created — in place, because NestJS registers them before any init hook runs and a parser appended later would sit behind the routes. Running during module init is what makes the limit hold under `Test.createTestingModule()`, which never runs `main.ts`. A path-scoped parser (`server.use('/upload', json({ limit }))` in `main.ts`) runs before the global one and is left untouched — that remains the way to give one path a different limit. Keep `server.useBodyParser('json')` (or `'urlencoded'`) in `main.ts` next to it: NestJS registers its global parser only when no layer with the same function name exists, so a path-scoped one registered before `app.init()` suppresses it, and every other path receives an empty body. Since 11.42.6 `CoreBodyParserInitializer` warns at boot in that case.
 
 The parser runs **before authentication and routing**. Over the limit, the whole request is refused:
 

package/migration-guides/11.42.3-to-11.42.4.md

@@ -63,6 +63,14 @@ server.useBodyParser('json', { limit: '2mb' });
 bodyParser: { json: { limit: '2mb' } },
 ```
 
+**Exception: keep `useBodyParser()` when `main.ts` also registers a path-scoped parser** such as
+`server.use('/upload', json({ limit: '20mb' }))`. NestJS registers its own global parser only if no
+layer with the same function name exists yet, and a path-scoped `json()` registered before
+`app.init()` counts as one. Removing `useBodyParser()` then leaves the app without a global JSON
+parser: every request outside that path reaches its handler with an empty body, and a sign-in fails
+with a validation error. Keep `server.useBodyParser('json')` (the configured limit is applied to it)
+and set the limit in the config as above. Since 11.42.6 the server warns at boot when it finds this.
+
 **Starter-based projects:** `config.env.ts` builds `local` / `e2e` / `ci` from `localConfig()` and the
 deployed environments from `deployedConfig()`. Put the limit where BOTH see it — the starter ships a
 shared `PROJECT_BODY_PARSER` constant for this since its 11.42.4 update — or set
@@ -75,7 +83,8 @@ The config is applied during module init, so it holds in every test that builds
 global parser your `main.ts` registered; keeping both is harmless, but the config wins.
 
 A **path-scoped** parser is left alone: `server.use('/upload', json({ limit: '20mb' }))` in `main.ts`
-still gives that one path its own limit. The parser runs before routing, so a per-route limit can only
+still gives that one path its own limit, as long as the global parser stays registered next to it
+(see the exception above). The parser runs before routing, so a per-route limit can only
 key on the path — and all GraphQL operations share one.
 
 **`rawBody: true`:** `req.rawBody` is kept for apps created with `NestFactory.create(…, { rawBody:

package/migration-guides/11.42.5-to-11.42.6.md

@@ -0,0 +1,97 @@
+# Migration Guide: 11.42.5 → 11.42.6
+
+## Overview
+
+| Category             | Details                                                                                                      |
+| -------------------- | ------------------------------------------------------------------------------------------------------------ |
+| **Correction**       | The 11.42.3 → 11.42.4 guide told every project to drop `useBodyParser()` from `main.ts`. With a path-scoped parser in `main.ts` that removes JSON parsing everywhere else (§1) |
+| **Improvement**      | The server warns at boot when NestJS skipped its global body parser because of such a path-scoped one (§1)   |
+| **Tooling**          | `check:overrides` no longer reports a failed audit as clean, and its probe follows `pnpm_config_registry` (§2) |
+| **Breaking Changes** | None                                                                                                         |
+| **Migration Effort** | None for most projects. Projects that removed `useBodyParser()` while registering a path-scoped parser in `main.ts` must add it back (§1) |
+
+## Quick Migration
+
+```bash
+pnpm update @lenne.tech/nest-server
+```
+
+Then check `main.ts` as described in §1. Vendor-mode projects pick up the core update and need the
+same check.
+
+## 1. Keep `useBodyParser()` next to a path-scoped parser
+
+§1 of the [11.42.3 → 11.42.4 guide](./11.42.3-to-11.42.4.md) recommended moving the body limit from
+`main.ts` into `bodyParser.json.limit` and deleting the `useBodyParser()` call. That is right, with one
+exception the guide did not name.
+
+NestJS registers its own global JSON and URL-encoded parsers inside `app.init()`, but only when no
+layer with the same function name exists yet. It compares the NAME and nothing else. A path-scoped
+parser registered in `main.ts` before `listen()` carries that name:
+
+```typescript
+// main.ts
+server.use('/diagnostics', json({ limit: '256kb' })); // a layer named `jsonParser`
+```
+
+With `useBodyParser()` removed, NestJS treats the JSON parser as already applied and registers none.
+Every request outside `/diagnostics` then reaches its handler with an empty body. A sign-in fails with
+a validation error such as "Missing input", and before this release nothing was logged.
+
+**Check `main.ts`.** If it registers `json(...)` or `urlencoded(...)` on a path, keep or restore the
+global parser next to it:
+
+```typescript
+// main.ts
+server.use('/diagnostics', json({ limit: '256kb' }));
+server.useBodyParser('json'); // the configured bodyParser.json.limit is applied to it
+```
+
+Keep the limit itself in the config (`bodyParser.json.limit`), where it also holds under
+`Test.createTestingModule()`. The e2e suite cannot catch the missing parser: the testing module never
+runs `main.ts`, so it never registers the path-scoped parser either.
+
+Since 11.42.6 the server logs a warning at boot in exactly this situation:
+
+```
+No global json body parser is registered: NestJS skips its own when a layer named `jsonParser`
+already exists, and a path-scoped `json()` parser registered before `app.init()` counts as one. …
+```
+
+The framework only reports it. It does not register the missing parser itself: NestJS would have put
+it after everything `main.ts` registered, and that position is no longer known during module init. A
+raw-body webhook or a proxy registered after the path-scoped parser must keep receiving the unread
+request stream.
+
+## 2. `check:overrides`: a failed audit is no longer reported as clean
+
+Two fixes in `scripts/check-overrides.mjs` (and the shared registry block in `scripts/check.mjs`):
+
+- When pnpm 11 cannot reach the registry, `pnpm audit --json` prints
+  `{"error": {"message": "fetch failed"}}` instead of a report. The guard read that as "0 advisories"
+  and printed `ok — N override(s) checked … none is failing`. It now prints
+  `could not obtain an audit report` (exit 0) on a live run, and fails (exit 1) when the failed report
+  was passed in with `--audit-file`, which is the CI path. The suppression checks still run in that
+  case, because they ask the GitHub Advisory API rather than the audit: a suppressed advisory that
+  gained a fix still fails with `FIX AVAILABLE`.
+- The clean-tree probe reads `pnpm_config_registry`, the variable pnpm 11 audits against. It used to
+  read `npm_config_registry`, which pnpm 11 ignores, and could then ask a registry the audit never used.
+
+`scripts/` is not part of the npm package. Projects created from nest-server-starter or lt-monorepo
+receive these fixes with their template update.
+
+## Troubleshooting
+
+| Symptom | Cause | Fix |
+| ------- | ----- | --- |
+| Boot warning "No global json body parser is registered" | `main.ts` registers a path-scoped `json()` and no global parser | Add `server.useBodyParser('json')` to `main.ts` (§1) |
+| Requests arrive with an empty body outside one path; sign-in reports "Missing input" | Same cause, on a version before 11.42.6 | Same fix (§1) |
+| `check:overrides` prints `could not obtain an audit report (fetch failed)` | The npm registry was not reachable during the audit | Re-run with network access, or pass a captured report with `--audit-file` |
+| `check:overrides` fails with `records a failed audit, not a result` | The report passed with `--audit-file` is a pnpm error, not an audit | Capture the report again once the registry answers |
+
+## Module Documentation
+
+- [REQUEST-LIFECYCLE.md — 0d. Body parsers](../docs/REQUEST-LIFECYCLE.md)
+- [11.42.3 → 11.42.4 guide §1](./11.42.3-to-11.42.4.md)
+- `.claude/rules/configurable-features.md` — Body Parser Limits row
+- `.claude/rules/package-management.md` — the `check:overrides` guard

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/nest-server",
-  "version": "11.42.5",
+  "version": "11.42.6",
   "description": "Modern, fast, powerful Node.js web framework in TypeScript based on Nest with a GraphQL API and a connection to MongoDB (or other databases).",
   "keywords": [
     "node",

package/src/core/common/interfaces/server-options.interface.ts

@@ -2335,6 +2335,11 @@ export interface IServerOptions {
    * (`server.use('/upload', json({ limit }))`) is left alone, and stays the way to give ONE path a
    * different limit, since the parser runs before routing and GraphQL shares a single path anyway.
    *
+   * Keep `server.useBodyParser('json')` in `main.ts` next to such a path-scoped parser. NestJS
+   * registers its own global parser only if no layer with the same function name exists yet, so a
+   * path-scoped `json()` registered before `app.init()` makes it skip the global one, and requests
+   * outside that path arrive with an empty body. The initializer warns at boot when it finds that.
+   *
    * One caveat: under the testing module the options passed to `createNestApplication()` are not
    * visible to providers, so a test app created with `{ rawBody: true }` gets no `req.rawBody` from
    * a CONFIGURED parser. Applications created with `NestFactory.create()` are not affected.

package/src/core/common/services/core-body-parser.initializer.ts

@@ -90,11 +90,8 @@ export class CoreBodyParserInitializer implements OnModuleInit {
       const limit = this.resolveLimit(type, config?.[type]?.limit);
       const layers = stack.filter((layer) => this.isGlobalParserLayer(layer, type));
 
-      if (limit !== undefined && !layers.length) {
-        this.logger.warn(
-          `bodyParser.${type}.limit is configured, but no global ${type} body parser is registered ` +
-            '(was the app created with `bodyParser: false`?) — the limit has no effect.',
-        );
+      if (!layers.length) {
+        this.warnMissingGlobalParser(type, stack, limit);
         continue;
       }
 
@@ -147,6 +144,18 @@ export class CoreBodyParserInitializer implements OnModuleInit {
     return layer?.slash === true && typeof layer.handle === 'function' && layer.handle.name === PARSER_NAMES[type];
   }
 
+  /**
+   * Whether the application was created without `bodyParser: false`.
+   *
+   * Read from the same container options as `rawBody`. Under `Test.createTestingModule()` those
+   * options never reach the container, so the answer there is always "enabled".
+   */
+  protected isBodyParserEnabled(): boolean {
+    const container = (this.moduleRef as unknown as { container?: { contextOptions?: { bodyParser?: boolean } } })
+      ?.container;
+    return container?.contextOptions?.bodyParser !== false;
+  }
+
   /**
    * Whether the application was created with `rawBody: true`.
    *
@@ -210,6 +219,39 @@ export class CoreBodyParserInitializer implements OnModuleInit {
     );
   }
 
+  /**
+   * Explain why there is no global parser of this type, when there should be one.
+   *
+   * NestJS registers its own parsers inside `app.init()` only if no layer with the parser's function
+   * name exists yet (`ExpressAdapter.isMiddlewareApplied()` compares the NAME and nothing else). A
+   * path-scoped `server.use('/upload', json({ limit }))` in `main.ts` therefore counts as "applied",
+   * NestJS skips its global parser, and every request outside that path reaches its handler with an
+   * empty body — a sign-in fails with a validation error, and nothing says why. Restoring the parser
+   * from here is not safe: NestJS would have placed it after everything `main.ts` registered, and that
+   * position is no longer knowable during module init (a raw-body webhook or a proxy registered after
+   * the path-scoped parser must keep seeing the unread stream). So this reports, with the remedy.
+   */
+  protected warnMissingGlobalParser(type: CoreBodyParserType, stack: ExpressLayer[], limit: number | undefined): void {
+    const name = PARSER_NAMES[type];
+    const shadowed = stack.some((layer) => layer?.slash !== true && layer?.handle?.name === name);
+    if (shadowed && this.isBodyParserEnabled()) {
+      this.logger.warn(
+        `No global ${type} body parser is registered: NestJS skips its own when a layer named \`${name}\` ` +
+          `already exists, and a path-scoped \`${type}()\` parser registered before \`app.init()\` counts as one. ` +
+          `Every request outside that path reaches its handler with an EMPTY body. Register the global parser ` +
+          `in main.ts as well — \`server.useBodyParser('${type}')\` — a configured \`bodyParser.${type}.limit\` ` +
+          'is applied to it.',
+      );
+      return;
+    }
+    if (limit !== undefined) {
+      this.logger.warn(
+        `bodyParser.${type}.limit is configured, but no global ${type} body parser is registered ` +
+          '(was the app created with `bodyParser: false`?) — the limit has no effect.',
+      );
+    }
+  }
+
   /**
    * Wrap a parser so its 413 is translated, keeping the name NestJS identifies the layer by.
    *