docfy export

Démarre l'app Nest de ton propre projet et écrit le document OpenAPI, sans lier de port ni avoir besoin d'infrastructure en direct.

Pourquoi ça existe

La seule chose dont SwaggerModule.createDocument() a structurellement besoin, c'est une app Nest entièrement initialisée : son conteneur DI doit résoudre chaque provider avant que les métadonnées de routes et de DTO existent pour être introspectées.

Ça n'exige pas .listen(). Aucun port n'est lié.

En pratique, ça n'exige généralement pas non plus d'infrastructure en direct : la plupart des clients TypeOrmModule, ioredis et kafkajs se connectent paresseusement plutôt que de bloquer le bootstrap, donc export fonctionne en général même avec la base de données, Redis et Kafka tous arrêtés.

Usage

Fournis un petit fichier d'entrée (les mêmes lignes que ton main.ts a déjà, moins .listen()) :

ts
// docfy-export.ts
import { NestFactory } from '@nestjs/core';
import { DocumentBuilder, SwaggerModule } from '@nestjs/swagger';
import { AppModule } from './app.module';

export default async function () {
  const app = await NestFactory.create(AppModule, { logger: false });
  const config = new DocumentBuilder().setTitle('My API').setVersion('1.0.0').build();
  const document = SwaggerModule.createDocument(app, config);
  return { app, document }; // `app` gets closed for you afterward
}
bash
npx nestjs-docfy export --entry docfy-export.ts --out openapi.json

La sortie informative va toujours vers stderr, jamais stdout, donc c'est sûr de faire un pipe : npx nestjs-docfy export --entry docfy-export.ts > openapi.json.

Le contrat du fichier d'entrée

L'export par défaut est une fonction asynchrone qui renvoie { app, document }. export l'exécute dans un processus enfant, sérialise document, et appelle app.close() pour toi ensuite.

Un fichier d'entrée .ts nécessite ts-node comme devDependency de ton projet (et tsconfig-paths aussi, pour les alias de chemin comme @app/common).

Options

OptionDefaultDescription
--entry <path>(required).ts/.js file whose default export returns { app, document }
--out <path>stdoutWhere to write the document
--root <path>.Project root — where ts-node/tsconfig-paths are resolved from
--quietfalseSuppress informational output
Quand ça n'aide pas

Un provider avec une connexion réellement immédiate et bloquante dans son constructeur ou onModuleInit ne bénéficiera pas de ce contournement d'infra. Rien dans export ne peut changer la façon dont tes propres providers se connectent. Ça évite seulement la seule chose dont NestJS lui-même n'a pas besoin : un port ouvert.