#Using ConfigModule to provide env variable inside another Module file

8 messages · Page 1 of 1 (latest)

royal compass
#

Hey everyone 👋

I am trying to inject an env variable loaded from the ConfigModule inside another "import" of another module - but I can make it work, where is the issue here ?

app.module.ts

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    LogsModule,
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

logs.module.ts

@Module({
    imports: [
        MongooseModule.forRoot(process.env.MONGO_URL_LOGS)
    ],
    exports: [
        LogsService
    ],
    providers: [
        LogsService
    ]
})
export class LogsModule {}

It says it can't connect to database, but when I hardcode the URL it's working. So I suspose that at this point, the env variable is not loaded yet
(Yes, there is a .env file, containing the variable, at the root level of the project)

Thank you in advance for your help 🙏

viral roost
#

MongooseModule.forRootAysnc(), like our docs show...

royal compass
#

Inside "Mongo" section... it should be inside Configuration instead, it's not only scoped to Mongo
Thank you

viral roost
#

There's an "Async Configuration" section in most of the related Techniques

#

Caching: https://docs.nestjs.com/techniques/caching#async-configuration
Typeorm: https://docs.nestjs.com/techniques/database#async-configuration
Queues: https://docs.nestjs.com/techniques/queues#async-configuration
Graphql: https://docs.nestjs.com/graphql/quick-start#async-configuration

And we make a mention of the use of forRootAsync methods inour Dyanmic Modules portion of the docs too: https://docs.nestjs.com/fundamentals/dynamic-modules#community-guidelines

Sorry it wasn't where you expected, but this is well documented

royal compass
#

Yeah yeah, I am not pointing out a lack of documentation, just noticed the confusing place of it, maybe it's just me 🙂

Thank for the time you gave me 🙏

viral roost
#

It's also dependent on the modules to expose this forRootAsync/registerAsync functionality, so we can't put a blanket statement in the config part of the docs saying "this is how to do it" because if there are modules (even ones not published by @nestjs/) that don't adhere to this standard, we'll get issues in our repo about "It doesn't work", when really it's not the fault of the ConfigModule, but of themodule trying to make use of the ConfigService