ConfigService uses .env file values ONLY when schemaValidation is provided about config

[kamilmysliwiec]

It is a regression. It used to work the way I described.

The behavior has changed in the latest major version. Major versions typically introduce breaking changes. The current solution - env file takes precedence over the system env variables - is an expected outcome and we don't plan to change it.

I'm not sure how you could easily specify a different .env file for tests.

You can load different .env files based on, for example, the NODE_ENV variable (which you can set using the cross-env, as in your example).

It's not consistent. When validation is on it prefers the .env file value. When validation is off it prefers the command line env var. That is a bug.

@greenreign this is indeed a bug and should be fixed as soon as possible. In both scenarios (validation either off or on), .env file values should override system variables. I'm gonna look at your PR right now but it might be hard to merge it ATM since it affects a different thing as well.

[kamilmysliwiec]

Apologies on the confusion @gperdomor, you're actually right..

A little bit more context here #213 (comment)

I'll add the "overrideProcessEnv" configuration property shortly (in case someone would like the dotenv vars to take the precedence).

[greenreign]

I should have a PR up shortly

[greenreign]

@kamilmysliwiec PR is up ⬆️ #170

[greenreign]

Is there anything else I can do to get this reviewed/approved? The longer it sits out here the more people may begin relying on the actual bug and would be impacted once it's fixed. It's also preventing my project from doing some pretty basic things we need to do to keep moving.

[prateekkathal]

@greenreign May I ask an example of why you'd want the process envs taking precedence over env file variables?

Personally I feel envFile variables are meant to override system env vars. I mean, that's one reason why they exist within your repo right? Otherwise why declare them inside your env file when you want them directly coming from your system?

[greenreign]

@prateekkathal

Sure, my team has used this with nestjs to override env variables with scripts.

For example, my .env file may point to my local MySQL db

DB_NAME=local

However, when I run tests I'd like to point to a test db so data is not mixed with my local testing. So I may have a script in my package json

"test": "cross-env DB_NAME=test jest"

1. ^ That used to work. It does not anymore.
2. Also, it behaves differently if you do not use validation

[prateekkathal]

@greenreign When running tests you can specify a different env file to be used. I personally do the same.

I feel this is a matter of preference between the precedence order and can conflict other applications. I'll leave the final decision on Kamil for this. 😄

[greenreign]

@prateekkathal It's not a matter of preference at all:

1. It is a regression. It used to work the way I described.
2. It's not consistent. When validation is on it prefers the .env file value. When validation is off it prefers the command line env var. That is a bug.

I'm not sure how you could easily specify a different .env file for tests. That option has to be passed in from somewhere, assuming you are not suggesting I edit the code each time. So it would be best to be defaulted the .env file and overridden by a scripted env var.
Thus, it has the same problem.

[prateekkathal]

@greenreign Some people want to override default system environment values, I am not sure how they'll be able to do that if we change the precedence. Like I said, it's a matter of preference. Nothing to argue here 😄.

The ConfigService takes in the env file value when initialized. I just use that.

Again, the final decision rests on Kamil. Good luck! 👍

[greenreign]

Some people want to override default system environment values,

@prateekkathal That makes sense. It does. But how did they do that in nest6? They couldn't because the system env variables took precedence and that was changed inadvertently but not universally.

Again, it's not a matter of preference unless you only look at nest/config after nest7 and with joi schema validation turned on. Then you get a choice. In any other scenario you do not.

[prateekkathal]

@greenreign I only said it is a matter of preference because of these issues opened in the past in the main dotenv repo - motdotla/dotenv#115 & motdotla/dotenv#199

Although, the issues were closed because the dotenv team doesn't prefer it, but there are other users who want that ability.

Now, I have nothing else to say. I am not the decision maker here & I am not saying your PR doesn't make sense. All I am saying, different people expect different results. So maybe we should approach this override ability in a different way.

Anyways, whatever the final decision will be, I'm okay with that. 😄

[kamilmysliwiec]

OK I've manually updated the PR and merged it in. Published as 0.4.1

[greenreign]

Fair enough. Thanks!

[afaure-bkk]

@kamilmysliwiec I find that letting the env variables take precedence makes it easier when running nest server in container: trivial to override values via docker command line or docker-compose, less trivial to update the config file on container startup (e.g.: dockerize).

So I ll be waiting for the new option :)