The CLI plugin

This is the same mechanism @nestjs/swagger's own CLI plugin uses to work under webpack: true. That's why @ApiProperty() isn't required on every DTO property even in a webpack build. The Nest CLI feeds a TypeScript compiler-plugin hook (compilerOptions.plugins) into both the tsc and the webpack (ts-loader) builder identically.

Register the plugin

Register nestjs-docfy in nest-cli.json:

{
  "compilerOptions": {
    "webpack": true,
    "plugins": ["nestjs-docfy"]
  }
}

import { applyDocfyMetadata } from 'nestjs-docfy';

const document = SwaggerModule.createDocument(app, config);
SwaggerModule.setup('api', app, applyDocfyMetadata(document));

Automatic detection

Forgetting to register the plugin is easy to miss until a build ships without documentation, so every generate run already checks nest-cli.json and prints a warning when webpack: true is set without the plugin. Pass --register-plugin to have it fix that for you instead of editing the file by hand:

npx nestjs-docfy generate --register-plugin

This is opt-in on purpose, since some teams deliberately stick to patch-spec instead of a compiler plugin, so generate never edits nest-cli.json unless you explicitly ask it to. It appends to any existing compilerOptions.plugins array (recognizing both string and object-form entries as already registered) and respects --dry-run.

How it works

nestjs-docfy's plugin doesn't rewrite any decorator syntax or touch the AST at all. On every compilation it re-runs the exact same static analysis generate/check/patch-spec already do (via ts-morph, against the source tree, not the bundle) and writes the resulting patch to docfy-metadata.json next to the build output.

Then, right after SwaggerModule.createDocument(), applyDocfyMetadata() reads that file and merges it in. There's no require.cache involved and no bundled-class-identity problem, because it never needs the running app to compute anything.

vs. patch-spec