@lenne.tech/nest-server 11.43.1 → 11.43.2

package/.claude/rules/package-management.md

@@ -169,7 +169,13 @@ Two ordering rules, both enforced by the contract test:
 Package overrides live in the `overrides:` section of **`pnpm-workspace.yaml`** (they moved out of `package.json`'s `pnpm.overrides` in the pnpm 11 upgrade). They force transitive dependencies to a security-patched version.
 
 **Keep the set minimal.** On the pnpm 11 upgrade the list was pruned from 36 to the 9 then still
-load-bearing (it has since grown back to 19 as new advisories landed) — an override is only necessary if removing it lets the package resolve back INTO its vulnerable range (verify with a with/without lockfile diff; `pnpm audit` is the arbiter). Each surviving entry carries its CVE rationale as a comment. Remove an entry once its parent dependency ships a fixed version.
+load-bearing (it has since grown back to 20, mostly as new advisories landed) — an override is only necessary if removing it lets the package resolve back INTO its vulnerable range (verify with a with/without lockfile diff; `pnpm audit` is the arbiter). Each surviving entry carries its CVE rationale as a comment. Remove an entry once its parent dependency ships a fixed version.
+
+**The one exception is a peer conflict nobody downstream can fix.** `'@nestjs/cli>webpack'` (added
+2026-10-20) carries no advisory: @nestjs/cli exact-pins a webpack that a newer transitive
+`schema-utils` refuses as a peer, so every fresh resolve fails `pnpm peers check`. Such an entry
+is parent-scoped (`parent>child`), so only the stale pin moves, and it states the release that
+lets it go. For such an entry `pnpm peers check` is the arbiter, not `pnpm audit`.
 
 ### Rule: Override Targets MUST Be Fixed Versions
 

package/FRAMEWORK-API.md

@@ -1,6 +1,6 @@
 # @lenne.tech/nest-server — Framework API Reference
 
-> Auto-generated from source code as of 2026-10-20 (v11.43.1)
+> Auto-generated from source code as of 2026-10-20 (v11.43.2)
 > File: `FRAMEWORK-API.md` — compact, machine-readable API surface for Claude Code
 
 ## CoreModule.forRoot()

package/migration-guides/11.43.1-to-11.43.2.md

@@ -0,0 +1,81 @@
+# Migration Guide: 11.43.1 → 11.43.2
+
+## Overview
+
+| Category             | Details                                                                                                  |
+| -------------------- | -------------------------------------------------------------------------------------------------------- |
+| **Bugfixes**         | A fresh dependency resolve passes `pnpm peers check` again — two upstream releases from 2026-10-18/19 made it report unmet peers for `webpack` and `browserslist` (§1) |
+| **New Features**     | None                                                                                                     |
+| **Framework API**    | Unchanged                                                                                                |
+| **Dependencies**     | Runtime dependencies unchanged. Build-time only: the `browserslist` override target is raised to `4.29.4`, and `'@nestjs/cli>webpack': '5.112.0'` is new — both in this repository's `pnpm-workspace.yaml`, which your project does not inherit (§1) |
+| **Internal**         | `pnpm run build` in this repository no longer rewrites `FRAMEWORK-API.md` when only the date in its header would change. No effect on consumers |
+| **Breaking Changes** | None                                                                                                     |
+| **Migration Effort** | None for most projects. A project whose `pnpm peers check` reports one of the two peers below adds or raises one override entry each (§1) |
+
+## Quick Migration
+
+```bash
+pnpm update @lenne.tech/nest-server
+```
+
+Vendor-mode projects pick it up with the core update. No code or configuration change is required.
+
+## 1. `pnpm peers check` fails after a fresh resolve
+
+Two upstream releases broke the peer check for every project that resolves its dependencies anew — a fresh
+`lt fullstack init`, a `pnpm update`, a `pnpm run update`, or an install without a lockfile. A lockfile resolved
+before 2026-10-18 hides both, so an existing project usually sees them at its next refresh.
+
+**`webpack`, required by `schema-utils`.** `schema-utils` 4.8.0 (published 2026-10-18) declares
+`peerDependencies.webpack: ^5.112.0`. It is reached through webpack's own plugins, while `@nestjs/cli` 11.0.24 — the
+newest 11.x — pins webpack to exactly `5.106.2`. The pin cannot satisfy the peer.
+
+**`browserslist`, required by `update-browserslist-db`.** A project that carries the starter's
+`'browserslist@<4.28.7': '4.29.3'` override (a security entry, see [security-overrides](../docs/security-overrides.md))
+also has pnpm rewrite `update-browserslist-db`'s peer range to that target. Consumers the key does not reach — in a
+fullstack workspace the app's CSS tooling, for example — resolve the newer `4.29.4` (published 2026-10-19), so the
+rewritten peer is unmet.
+
+Both are build-time only: `nest build` uses tsc unless `nest-cli.json` selects the webpack builder, and nothing at
+runtime imports either package.
+
+**What to do:** pnpm overrides apply only to the root of an install, so the entries in this repository do not reach
+your project. If `pnpm peers check` (or `pnpm run check`) reports either peer, add the entries to the `overrides:`
+section of your project's `pnpm-workspace.yaml` (the workspace root in a monorepo):
+
+```yaml
+overrides:
+  # existing entry from the starter: raise the target only
+  'browserslist@<4.28.7': '4.29.4'
+  # new: lifts only @nestjs/cli's exact webpack pin, nothing else
+  '@nestjs/cli>webpack': '5.112.0'
+```
+
+Then run `pnpm install` and `pnpm peers check` again. The webpack entry is parent-scoped on purpose: it moves only the
+CLI's stale pin, so no other consumer is held back. It can go once `@nestjs/cli` requests `webpack >=5.112` itself, or
+with `@nestjs/cli` 12, where webpack is a peer.
+
+`nest-server-starter` 11.43.2 carries both entries, so a project created after this release has them already.
+
+## Compatibility Notes
+
+| Pattern | Status |
+| ------- | ------ |
+| Existing lockfile, no refresh | Unchanged — the peer check stays green until the next resolve |
+| Fresh resolve without the entries | `pnpm peers check` reports `webpack` and/or `browserslist` — add the entries (§1) |
+| `nest-cli.json` with the webpack builder (`nest build --webpack`) | Builds with webpack 5.112.0 once the entry is in place |
+| Runtime behaviour | Unchanged — no runtime dependency moved |
+
+## Troubleshooting
+
+**`pnpm peers check` still reports `webpack` after adding the entry**
+Check that the key is exactly `'@nestjs/cli>webpack'` and that the entry sits in the `pnpm-workspace.yaml` of the
+install root. pnpm 11 reads overrides only from there, not from `package.json`.
+
+**pnpm refuses `4.29.4` or `5.112.0` with `ERR_PNPM_NO_MATURE_MATCHING_VERSION`**
+Your project enforces a `minimumReleaseAge` window that these versions have not cleared yet. Wait until they have
+rather than adding an exclusion.
+
+## Module Documentation
+
+- [Security overrides — why yours are not inherited](../docs/security-overrides.md)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/nest-server",
-  "version": "11.43.1",
+  "version": "11.43.2",
   "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",