Loading dotEnv file and ormconfig.js

[clovis1122]

Issue type:

[ ] question
[ ] bug report
[x] feature request
[ ] documentation issue

Database system/driver:

[ ] cordova
[ ] mongodb
[ ] mssql
[ ] mysql / mariadb
[ ] oracle
[ ] postgres
[ ] sqlite
[ ] sqljs
[ ] react-native
[ ] expo

TypeORM version:

[x] latest
[ ] @next
[ ] 0.x.x (or put your version here)

Coming from Sequelize, this is a very awesome ORM!

I'm implementing multi-environment variables (.env, .env.testing) that is part of a Docker setup in my project. I created an ormconfig.js file and attempted to load my .env.testing using dotenv, but found out that someone had already loaded an environment.

It seems that Typeorm is pre-loading the dotEnv file in the ConnectionOptionsReader file without allowing the option to customize this load.

This introduces two issues for me:

1. If the variable TYPEORM_CONNECTION exists then my ormconfig.js file won't be loaded. This was probably intentional, but not a very intuitive behavior. Shouldn't explicit configurations (such as an ormconfig,js file) override the less explicit ones (such as a .env defined variable)?

2. I cannot load the environment that I want because Typeorm already loaded one and overriding already-defined environment variables is not supported by dotenv, due to security reasons.

The temporal workaround that I'm using is to override the env variables and also had to rename my env variables to avoid Typeorm not loading my ormconfig file.

Would it be possible to address (2) by giving the user the option to load the environment (or to specify the path) using a config file? For (1), would it be possible to attempt to load the ormconfig files before loading the .env variables?

[pleerock]

If the variable TYPEORM_CONNECTION exists then my ormconfig.js file won't be loaded. This was probably intentional, but not a very intuitive behavior. Shouldn't explicit configurations (such as an ormconfig,js file) override the less explicit ones (such as a .env defined variable)?

its controversial. Some people may point that they have development configuration in ormconfig and on production they want to override that using env variables.

why you simply won't override .env with your .env.testing (mount it, replace it or something)?

[clovis1122]

If the variable TYPEORM_CONNECTION exists then my ormconfig.js file won't be loaded. This was probably intentional, but not a very intuitive behavior. Shouldn't explicit configurations (such as an ormconfig,js file) override the less explicit ones (such as a .env defined variable)?

its controversial. Some people may point that they have development configuration in ormconfig and on production they want to override that using env variables.

why you simply won't override .env with your .env.testing (mount it, replace it or something)?

Thanks for taking the time to reply to this.

That use case is fine, though I think we should be more explicit on how Typeorm is loading the configuration file. Having implicit ordering can be a nightmare to debug later on.

Perhaps if we cannot solve the controversy, would it be fine to document this behavior in the documentation, so that people know how Typeorm decides from where to take the configuration?

As for the .env topic, we follow the convention of using a .env file for normal development (The file is overrided for prod) and .env.testing file for running the tests. This allow us to override certain configurations (e.g, the DB that's accessed, caching, logs, and other settings) that we would otherwise have to place in the code.

I cannot override the .env with the .env.testing because the development configuration would be lost.

[pleerock]

Perhaps if we cannot solve the controversy, would it be fine to document this behavior in the documentation, so that people know how Typeorm decides from where to take the configuration?

yeah, we can add docs. But there is also some discussion on what we shall do with current configuration loading. Feel free to PR against docs.

I think best in your case is to manually send options to createConnection function - options you need and you have full control of.

[clovis1122]

Perhaps if we cannot solve the controversy, would it be fine to document this behavior in the documentation, so that people know how Typeorm decides from where to take the configuration?

yeah, we can add docs. But there is also some discussion on what we shall do with current configuration loading. Feel free to PR against docs.

Done (thanks for the quick merging!).

I think best in your case is to manually send options to createConnection function - options you need and you have full control of.

Thanks, that could work. Because createConnection doesn't load the environment variable when you pass the options, I'm free to load any .env file that I want.

I'm not sure if it will also work for the CLI. I'll check and if it does, then I can close this issue.

[pleerock]

to make it to work with CLI probably you have only one option - left only ormconfig.js and setup what you need in there through env-related checks.

[clovis1122]

It is true that Typeorm will still load my .env and it looks like I cannot prevent it from the CLI (unless I do something like ts-node -r ./ormconfig.js to load the env before Typeorm tries to).

My options are: making Typeorm a special case and tell my team that the configuration of the project resides in both the .env files and the ormconfig.js file, or use a workaround (like overriding env variables or preloading a module that sets the correct .env before Typeorm is executed).

It seems to me that this specific behavior of Typeorm (Loading the env file) is causing an undesirable effect. However, I understand that it has it's use cases.

Would you accept PRs to customize this behavior under an option, or under a flag for the CLI?

Thanks!

[pleerock]

We are planning to rework this mechanizm in the future, so I want to prevent additional specific changes in the current implementation. If you found a solution for your use case its better to stay with it.

[clovis1122]

Sounds good, thanks!

I'll override the process.env variables for the time being.

Closing this issue.

[moltar]

Arguably it is outside of TypeORM's responsibility to manage .env files.

This is a very unexpected and magical behaviour.

This magical behaviour can lead to many issues.

Arguably implicitly reading config from any env is a bad behaviour.

What if I accidentally set an env variable and forget to unset it, and can destroy data this way.

I think the best way is to offload config loading to third party packages that can be loaded separately.

[grumpyoldman-io]

I just spend 2 hours finding out why my env vars are not being expanded properly, loading of custom .env.x vars is not that uncommon (it is the default in Create React App for instance).

I think it is bad practice to have a tool implicitly (magically) ingest env vars, especially when it is so easy to add env var loading in a ormconfig file. TypeOrm should be confined to what you explicitly put in.

[julia-suarez-deel]

Another case where I spent 2 hours figuring out why I wasn't able to load a .env.x file or why my .env was being loaded magically because yes, you don't expect for your orm to load your environment variables.

[pethaniakshay]

I too spent 1 hour and came across this thread. I want to explicitly set the env file but no way to do it.

[thauam09]

i'm facing the same problem. There is no way to implement this feature in the future?

[ordep2v]

same problem in 2022