Comment gérez-vous la configuration dans NestJS ?

Question

Accepted Answer

NestJS fournit le package **`@nestjs/config`** pour gérer la configuration et les variables d'environnement de manière structurée, type-safe et injectable. Il charge les fichiers `.env`, valide la config, et rend les valeurs disponibles dans toute l'application via le `ConfigService` injectable. ## Configuration de ConfigModule ```ts import { ConfigModule } from "@nestjs/config"; @Module({ imports: [ ConfigModule.forRoot({ isGlobal: true, // available app-wide without re-importing envFilePath: ".env", validationSchema: Joi.object({ // validate env vars at startup (fail fast) DATABASE_URL: Joi.string().required(), PORT: Joi.number().default(3000), JWT_SECRET: Joi.string().required(), }), }), ], }) export class AppModule {} ``` `ConfigModule.forRoot()` charge les variables d'environnement (depuis `.env` + l'environnement du processus) et — c'est crucial — peut **valider** avec un schéma (Joi), donc une config manquante ou invalide plante l'app au démarrage avec une erreur claire plutôt que d'échouer mystérieusement à l'exécution. ## Lecture de la config via ConfigService (injectable) ```ts @Injectable() export class DatabaseService { constructor(private configService: ConfigService) {} // inject ConfigService connect() { const url = this.configService.get("DATABASE_URL"); const port = this.configService.get("PORT", 3000); // with a default } } ``` Au lieu de lire `process.env` directement partout, vous injectez `ConfigService` et appelez `get()` — type-safe, testable, et centralisé. ## Configuration typée/en namespace ```ts // config/database.config.ts — group related config with registerAs export default registerAs("database", () => ({ host: process.env.DB_HOST, port: parseInt(process.env.DB_PORT, 10), })); // load it: ConfigModule.forRoot({ load: [databaseConfig] }) // access it: configService.get("database.host") ``` Le namespacing groupe les paramètres liés et garde la config organisée à mesure qu'elle grandit. ## Pourquoi ne pas simplement utiliser process.env directement ? ```text ✗ process.env scattered everywhere → hard to test, no validation, stringly-typed ✓ ConfigService → injectable (mockable in tests), validated at startup, typed, centralized — the structured NestJS way ``` ## Secrets et environnements ```text ✓ Keep secrets in .env (GITIGNORED) — commit a .env.example documenting required vars ✓ In production, inject config via the platform's env vars / secret manager ✓ Validate at startup so misconfiguration fails immediately with a clear message ``` ## Pourquoi c'est important Une gestion appropriée de la configuration est essentielle pour toute application réelle — gérer les URL de base de données, les clés API, les ports, les secrets, et les feature flags de manière sécurisée et flexible dans les différents environnements (dev, staging, production). Le `@nestjs/config` de NestJS fournit la manière structurée et idiomatique de faire cela, et la comprendre est une connaissance importante au quotidien. Les avantages clés par rapport à la lecture directe de `process.env` sont significatifs : le **`ConfigService`** injectable rend la config testable (mockable dans les tests) et centralisée ; la **validation au démarrage** (avec un schéma Joi) détecte immédiatement les configurations manquantes ou mal formées avec une erreur claire plutôt que comme une défaillance d'exécution confuse profonde dans une requête ; et le namespacing garde la config croissante organisée. Combinée avec la bonne pratique de sécurité de garder les secrets dans des fichiers `.env` ignorés par git (et un `.env.example` committé), cela vous donne une configuration sûre, portable et validée. Savoir comment configurer `ConfigModule`, injecter et utiliser `ConfigService`, et valider la config est fondamental pour construire des applications NestJS prêtes pour la production et reflète la pratique back-end professionnelle.