Les modules dynamiques sont des modules qui peuvent être configurés lors de leur importation — au lieu d'un @Module({...}) statique, ils exposent des méthodes statiques (conventionnellement forRoot et ) qui retournent un module configuré avec les arguments que vous passez. C'est ainsi que les modules configurables et réutilisables (config, base de données, JWT) acceptent des options.
forFeatureA static module is fixed — but reusable modules (DatabaseModule, ConfigModule,
JwtModule) need to be CONFIGURED per app (connection URL, secret, options).
Dynamic modules let a module accept configuration at import time.
@Module({
imports: [
ConfigModule.forRoot({ isGlobal: true }), // ← forRoot with options
TypeOrmModule.forRoot({ type: "postgres", url: ... }), // ← configured at import
JwtModule.register({ secret: process.env.SECRET }), // ← register variant
TypeOrmModule.forFeature([User, Post]), // ← forFeature for specifics
],
})
export class AppModule {}
Les appels .forRoot()/.register()/.forFeature() que vous voyez lors de l'importation de modules sont des méthodes de modules dynamiques acceptant une configuration.
forRoot() → configure the module ONCE, globally (the connection, the secret, core setup)
called in the root/app module a single time
forFeature() → register feature-specific pieces in each feature module that needs them
(e.g. TypeOrmModule.forFeature([User]) registers entities per module)
La convention : forRoot pour une configuration globale/ponctuelle ; forFeature pour une enregistrement par feature que vous appelez dans plusieurs modules.
@Module({})
export class StorageModule {
static forRoot(options: StorageOptions): DynamicModule {
return { // returns a configured module
module: StorageModule,
providers: [
{ provide: "STORAGE_OPTIONS", useValue: options }, // inject the passed options
StorageService,
],
exports: [StorageService],
global: true, // optionally make it global
};
}
}
// usage: StorageModule.forRoot({ bucket: "my-bucket", region: "us-east-1" })
La méthode statique retourne un objet DynamicModule (module + providers + exports), câblant les options passées dans les providers du module (souvent via un token d'injection).
// configure using OTHER injected dependencies (e.g. ConfigService) — async/factory
StorageModule.forRootAsync({
useFactory: (config: ConfigService) => ({ bucket: config.get("BUCKET") }),
inject: [ConfigService],
});
La variante forRootAsync permet que la configuration dépende d'autres providers (comme ConfigService) — essentiel quand les options proviennent d'une configuration validée.
Les modules dynamiques et le pattern forRoot/forFeature sont un concept important de NestJS pour construire des modules configurables et réutilisables — et les comprendre est précieux à la fois pour utiliser l'écosystème et pour construire des modules partagés.
Presque tous les grands modules NestJS (ConfigModule, TypeOrmModule, JwtModule, BullModule, CacheModule) sont des modules dynamiques configurés via .forRoot()/.register()/.forFeature(), donc reconnaître ce que sont ces appels (passer une configuration à un module au moment de l'importation, plutôt qu'une importation statique) démystifie comment tout l'écosystème est câblé.
La convention forRoot vs forFeature (forRoot pour une configuration globale ponctuelle comme une connexion à une base de données ou un secret ; forFeature pour un enregistrement par feature comme enregistrer des entités dans chaque module) est un pattern que vous rencontrez constamment.
Pour les développeurs seniors, savoir comment construire vos propres modules dynamiques (retourner un DynamicModule avec des providers configurés à partir des options passées, souvent via des tokens d'injection, avec des variantes asynchrones pour une configuration dépendante) est ce qui vous permet de créer des modules réutilisables et configurables — une infrastructure partagée (stockage, clients d'API externes, configuration personnalisée) que d'autres parties d'une application ou d'autres projets importent avec leurs propres paramètres.
C'est un sujet plus avancé, mais il est fondamental pour comprendre profondément l'architecture modulaire de NestJS et pour construire des bibliothèques de modules professionnelles et réutilisables, ce qui en fait une capacité importante pour architecting de grands systèmes NestJS bien structurés.