How to create dynamic, async, and configurable modules (chapter)

I’m submitting a…

[ ] Regression 
[ ] Bug report
[ ] Feature request
[x] Documentation issue or request (new chapter/page)
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Expected behavior

Ref https://github.com/nestjs/nest/issues/1415

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

For Tooling issues:
- Node version: XX  
- Platform:  

Others:

[Falven]

@kamilmysliwiec

I’m not sure why this thread is closed; I think in general the NestJs framework STILL lacks both documentation AND methods for clearly and concisely setting the DI lifetime/scope of modules. It is confusing for both new and seasoned developers to try to understand the relationship between module lifetimes and provider lifetimes and both can get mixed up/confused easily. Also, the forRoot pattern is still not well documented nor does it connect with the framework in any way as it is just a made up convention with a static function returning an object.

One such complexity that is hard to grasp is that when you are importing a module with imports: [MyModule.forRoot(...)] you are not really certain if this module will actually be a singleton accessible by other modules who later imports: [MyModule] given that you are not registering the MyModule type itself as the injection token, but rather the return value of the forRoot function which is an object of DynamicModule type.

To add to the complexity there are forRootAsync and forFeature patterns which are also not documented and a developer basically has to go clone and try to understand complicated framework wrapper modules, such as @nestjs/typeorm or @nestjs/mongoose, as examples for usage of these patterns.

It is also extremely hard to debug the IoC Container (what is injected, instantiated, where etc.) in NestJs. I still haven’t found a way how, except through something like nestjs-spelunker which, overall, is not a great debugging experience.

I think at a minimum, if you choose to go this direction with module configuration, the framework should provide an interface with these methods that modules implement. However, I still fundamentally disagree with this direction as it shouldn’t be this complicated to simply want to pass in some data to a module.

Edit: The article you posted on Advanced DynamicModules helps, but it barely scratches the surface of what is truly a major underlying problem with the framework. It’s also very badly SEO’d and took forever to find. It’s upsetting that a framework that looks so optimal/friendly to use at a high level ends up having such a boilerplate and unfriendly underbelly when you get into advanced concepts.

[AndyGura]

It is still not clear how to implement own forRootAsync method, just like it was asked here: https://github.com/nestjs/nest/issues/1415 and there is link to this issue. I want to do something like this:

MyModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: (configService: ConfigService) => ({
        someOption: configService.get<string>('SOME_ENV_VAR'),
      }),
    }),

I want it to work in the same way as

MyModule.forRoot({
      someOption: process.env.SOME_ENV_VAR,
    }),

And after a digging documentation for a while, I still can not find any suggestion how to do that. It would be cool to add code sample to official documentation. Thank you!