Passing validationOptions: { allowUnknown: false } causes errors for env values outside the schema about config

[kamilmysliwiec]

Is this considered a bad way of doing things?

Yes. There are 2 issues here:

• you should never import ConfigModule#forRoot() twice (as the name suggests, "forRoot")
• you should never define ConfigService (from @nestjs/config) as a provider

[jtlindsey]

Yes, if it is a bug and I figure out how to fix it. Based on it's current setup I don't imagine anyone is using allowUnknown: false because they would have to specify (in the schema) the other 227+ default environment variables that they may not be interacting with. Is this a bug or is this intended behavior?

process.env is hardcoded here. To prevent affecting functionality in other code interacting with config, it seems a good option would be for the user to pass a validation file here and have it default to .env. Does that make any sense or is it better to make a change on loadEnvFile and try to preserve the behavior of when users add custom environment files other than .env? I'm not familiar with nestjs codebase yet. My first nest new project-name was the day I opened the ticket.

[kamilmysliwiec]

What if someone wants to validate the actual env variables (and their presence), not only those specified in the .env file?

[liaoliaots]

This is expected behavior, not a bug.

Firstly, joi is a data validator for JavaScript, not only for nestjs, @nestjs/config is just a usage scene.

Secondly, the validationOptions option receives options for the validate method of the joi library. If validationOptions is not provided, @nestjs/config will return {abortEarly: false,allowUnknown: true}.

• For the allowUnknown option, it defaults to true because the joi library's allowUnknown option defaults to false and process.env has many environment variables.
• For the abortEarly option, it defaults to false because the joi library's abortEarly option defaults to true and to see which environment variables do not pass validation.

So it is not recommended to set the allowUnknown option to false in this scenario.

The environment variables come from the env file and the runtime environment. So the best practice is to throw an exception during application startup if required environment variables haven't been provided or if they don't meet certain validation rules.
Don't bother with additional environment variables.

[kamilmysliwiec]

Would you like to create a PR for this issue?

[prateekkathal]

@jtlindsey Yes, I realized the purpose of allowUnknown was only relevant to singular ConfigModule settings.

If you have multiple, obviously others will be unknown for it. So I stopped using it.

IMO, we should possibly store an array of all the validated env variables from all the different places where we used ConfigModule and then check for there is still an unknown variable inside the .env. But again, this setting must only correspond to the global module rather than all modules.

Not sure if I make sense here? 😅 CC: @kamilmysliwiec

[prateekkathal]

What if someone wants to validate the actual env variables (and their presence), not only those specified in the .env file?

Is this directed to me?

According to me if let's say we have 2 modules SessionConfigModule (eg SESSION_TTL) & CacheConfigModule (eg CACHE_TTL), setting { allowUnknown: false } in either of the modules should not throw any errors because both modules have the variables defined & validation added for them.

If let's say I add another variable QUEUE_LIMIT, then allowUnknown should throw an error, saying unknowns are not allowed.

Currently, setting { allowUnknown: false } in either of the modules will throw an error, which isn't right I feel.

So as suggested in my previous message, if we are able to create a list of all the defined variables & validate all (run this) in one go instead of separately for each module, that should resolve the issue I think.

[kamilmysliwiec]

According to me if let's say we have 2 modules SessionConfigModule (eg SESSION_TTL) & CacheConfigModule (eg CACHE_TTL), setting { allowUnknown: false } in either of the modules should not throw any errors because both modules have the variables defined & validation added for them.

Not sure what you mean. ConfigModule#forRoot should never be called more than once within a single application.

[prateekkathal]

According to me if let's say we have 2 modules SessionConfigModule (eg SESSION_TTL) & CacheConfigModule (eg CACHE_TTL), setting { allowUnknown: false } in either of the modules should not throw any errors because both modules have the variables defined & validation added for them.

Not sure what you mean. ConfigModule#forRoot should never be called more than once within a single application.

@kamilmysliwiec How do you propose we allow creation of multiple config modules? For eg: AppConfigService or CacheConfigService?

AppConfigService will only support env variables prefixed with APP_ & CacheConfigService will only support env variables prefixed with CACHE_?

[kamilmysliwiec]

@kamilmysliwiec How do you propose we allow creation of multiple config modules?

Create wrapper services that use the built-in ConfigService under the hood.

[prateekkathal]

@kamilmysliwiec Is this considered a bad way of doing things?

This helps me import: [CacheConfigModule] or import: [AppConfigModule] only where it is is required, rather than globally importing the ConfigModule inside AppModule.

[prateekkathal]

@kamilmysliwiec Understood. Thanks.

[rteano]

What if someone wants to validate the actual env variables (and their presence), not only those specified in the .env file?

@kamilmysliwiec I am currently experiencing this issue and so I opted not to use the validation option anymore. It would be nice if we can have a flag that tells the config module to do a strict validation only to env files or with .env by default and add additional validation with env vars not included in any env file/s if a user insist as you mentioned to validate an actual env var not included in any env file/s.

@prateekkathal I happen to read about your blog about nestJS folder structuring as I am also new to the framework. I did a little tweak to avoid issues mentioned by kam (but I am not sure if this is correct too). I only imported ConfigModule for each config module (app, db etc...) so I can inject ConfigService in the each service and had the ConfigModule#forRoot imported to my root config module which I am importing to the app module. This works for me, but I am not sure if this is the best structure.