Handle JS runtimes .env autoloading

[andreafspeziale]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

While testing Bun JS runtime as drop-in Node.js alternative I noticed some glitches in my project automated tests.

While developing I usually have two env files:

• .env used to run the application eg. nest start --watch
• env/.env.test used in the tests by the ConfigModule leveraging the envFilePath option

Node.js does not load .env files automatically. They recently added .env file support in the latest versions but a flag would be required (based on my understanding).

Instead Bun will automatically load the .env and so at this config module line the already present env vars will be ignored. This means that leveraging envFilePath: join(process.cwd(), 'env/.env.test') will not produce the aimed configuration object.

The following screenshots should be pretty exhaustive:

Same here:

While:

Btw the same is not happening if actually using the dotenv path option

The following will return the expected env variables even if in the project root .env file exists. It will work even if (e.g) ran with Bun:

Or even with Node:

So at the end of the day ConfigModule envFilePath flag is a little bit misleading IMHO.

Describe the solution you'd like

All this crap can be mitigated in multiple ways:

• Bun implementing a flag in order to avoid loading by default .env
• Developer not having .env in the root and loading it by path in their core module (not huge fan)
• ConfigurationModule new option in order to avoid the "filter" pointed out in the above section

Let me know your thoughts and thanks for your hard work

Teachability, documentation, adoption, migration strategy

No response

What is the motivation / use case for changing the behavior?

Improve developer experience

[kamilmysliwiec]

Instead Bun will automatically load the .env and so at this config module line the already present env vars will be ignored.

This is the expected behavior.

Bun implementing a flag in order to avoid loading by default .env

Could you report this in the Bun repository?

[andreafspeziale]

This is the expected behavior.

As per:

• name of the ConfigModule envFilePath option
• the way plain dotenv lib works

I believe that the expected behavior of using envFilePath would be this as mentioned in the main PR comment

or at least along with some other option to make it happen avoiding breaking changes and keeping the current "implementation/expected behavior" leveraging default.

Could you report this in the Bun repository?

Sure, I'll see if makes sense to them