feat: add ignore env on get option

[rams23]

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• [x] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [x] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Other... Please describe:

What is the current behavior?

Up to now, there is no way to avoid the config service to read from the env. This can cause some problems while testing some features and trying to inject a specific configuration value (that could be overridden by process.env on get)

Issue Number: #245

What is the new behavior?

This pr adds ignoreEnvVarsOnGet that will not consider process.env while getting the variables from the ConfigService. So you can be sure that the returned value will be the one in the factory

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

[andrew-sol]

I think that total ignoring of the env vars is not what people actually want. Sure, it will do the job but it will require an additional environment check for some setups, like ignoreEnvVarsOnGet: process.env.NODE_ENV === 'development'.

If, for example, AWS infrastructure is used, then (most likely) AWS Secrets Manager is also used. So there are no .env.* files in production, only global env vars, and .env.* files exist only on local machines.

So we need a setting like prioritizeEnvFile: true (false by default). This way, if .env.* files exist, they will overwrite system-wide env vars, but the application will continue to pick up the global vars too.

[CeEv]

Let it like it is, is also no option. For some projects the nest configuration modul do not work. Let the projects the deciding what they need. The framework should they support and not force to anything. @andrew-sol hint is good, maybe this is a way to go

[vtgn]

I think that total ignoring of the env vars is not what people actually want. Sure, it will do the job but it will require an additional environment check for some setups, like ignoreEnvVarsOnGet: process.env.NODE_ENV === 'development'.

If, for example, AWS infrastructure is used, then (most likely) AWS Secrets Manager is also used. So there are no .env.* files in production, only global env vars, and .env.* files exist only on local machines.

So we need a setting like prioritizeEnvFile: true (false by default). This way, if .env.* files exist, they will overwrite system-wide env vars, but the application will continue to pick up the global vars too.

Hi,

I disagree.

I explained here why I need the ConfigService ignores totally the system global env vars. Like you can see, I give there another way to load a ConfigModule that you didn't mentioned: the use of a validated and customizable Typescript object of properties. And this is the perfect way to load and store in a property a secret from the AWS Secrets Manager on production env, or get a simply env var value from process.env on development or test envs. You can even define different config objects with different transformation's algorithms and different validation's schemas, depending on the current environment. ;)

Regards.