debug with dotenv about debug HOT 3 CLOSED

Thanks for the information for those users.

For what it's worth, some advice: if you want to use these tools properly, don't import dotenv. I'd personally consider it a stark anti-pattern that will cause you problems in the long run, anyway. Use the CLI utility to prefix anything you want to have load the environment variables from. It would (well, should) sidestep any of the nonsense surrounding .enable()/.disable() behavior.

Just my $0.02. Hardcoding anything about the environment into your source directly rarely works out for you in the long run.

EDIT: Huh. Doesn't seem that there's a CLI like I thought. This utility would be... well, rather trivial to wrap for any process that needs it, not just Node. Anyway, node -r dotenv/config ... should work, according to their docs. Stick it into your start script if you don't want to type it each time.

from debug.

I'm going to close this since it's not really an 'open' issue but if I see more issues filed w.r.t. dotenv in the future I'll pin this for visibility.

from debug.

Just my $0.02. Hardcoding anything about the environment into your source directly rarely works out for you in the long run.

In my case, I was trying to emulate the behaviour from the create-react-app, which I believe was based on the behaviour of the Ruby gem1 that existed before the JS dotenv project came to exist.
It worked by trying to load different .env files according to the detected environment.

So in my example, the // Do dotenv things section would rather look something like this:

import { existsSync } from 'node:fs'
import { cwd } from 'node:process'
import path from 'node:path'

...

// Do dotenv things
const nodeEnv = process.env.NODE_ENV ?? 'development'

const envFiles = [`.env.${nodeEnv}.local`, '.env.local', `.env.${nodeEnv}`, '.env']
    .filter((envFile) => existsSync(path.resolve(path.join(cwd(),envFile))))

for(const envFile of envFiles) {
    dotenv.config({ path: envFile })
}

As an example scenario, it would allow me to easily switch or (selectively) override (debug) settings.
Which could handy in case you have a generic .env file included in a Docker build and want to override only particular variables in a specific environment, or want or need to tune them. This is a safe(r) escape hatch without having to manage full environment variables and the potential discrepancies this might bring. (Which is obviously why dotenv-vault came to rise.)

Though, you are absolutely correct, this would ideally be implemented using a preload script that provides this functionality.

from debug.