GeezerVison

Review requested:

• @nodejs/startup

I think we'll get a number of follow up requests beyond the most basic functionality. A few that I think we should have some plan for:

• Using a custom path instead of .env file in the current working directory.
• The option to augment vs. overwrite the existing process.env with the values from the .env file.
• If we support augmenting, what happens on conflict (overwrite, don't overwrite, throw, etc.)?
• Programmatic API.
• The ability to put the loaded values in an object other than process.env.
• Multiline values.
• Comments in the .env files.
• Variable expansion.

Note, some of these are taken directly from the dotenv module's README.

regarding testing and validation, you can take dotenv's test suite (which afaik is the most popular package for parsing .env files): https://github.com/motdotla/dotenv/tree/master/tests

my other concerns were already mentioned just before I was about to comment

I think we’ll get a number of follow up requests beyond the most basic functionality.

I think it’s okay if we define our scope as more limited than dotenv‘s, and if people want something more full-featured then they should just use dotenv. Ultimately the point of adding this is to fix #48852 and #43973, to just provide a way to configure Node, and the ability to set other environment variables beyond NODE_OPTIONS is a side benefit.

That said, from your list I already mentioned allowing specifying the path to the file, and I think we need to at least document what we do for conflicts; I think the simplest approach is to just always have the “real” environment variable win out over whatever is defined in the file, and leave it at that. It would be nice to ignore lines starting with # as comments, as that should hopefully be pretty easy. The rest I think we could consider out of scope, at least for now.

One other thing we should do is mark this as experimental in the docs.

Supporting incremental .env files would be great (e. .env.test with overrides over generic .env)

See, the feature requests already start piling up...

Apart from this being an infinitely slippery slope, I also feel it goes directly against node's "mechanism over policy" philosophy. Not a fan.

Please consider adding support for env expand. It's insane to think that dotenv-expand has 12 million weekly download which has no defined grammer.

test$var
test${var
test$var}
test$var:-$hmm
test${var:-$hmm

the list goes on. Too much regex in Node community 🙂

Please consider adding support for env expand. It's insane to think that dotenv-expand has 12 million weekly download which has no defined grammar.

I think it can be implemented as a follow-up pull request, if anyone is interested in implementing. I'm in favor of keeping the implementation as small as possible (for now).

What is this feature's interaction with the permission model?

What is this feature's interaction with the permission model?

@panva If we want to support NODE_OPTIONS, it needs to bypass permission model, since V8 will not be initialized at that time.

@panva If we want to support NODE_OPTIONS, it needs to bypass permission model, since V8 will not be initialized at that time.

So an env variable that pretty much can override node options... That is honestly risky in many fronts even more when it boils down to bypassing permission mode options.

@nodejs/tsc This seems like the kind of thing the TSC should have an opinion on.

CI: https://ci.nodejs.org/job/node-test-pull-request/53393/

CI: https://ci.nodejs.org/job/node-test-pull-request/53394/

Landed in 769823e

Thanks @anonrig! You've saved a few hundred thousand people (maybe more) a little work by including this! ❤️

Which is the standard or recommended file pattern? .env.foo or .foo.env? Corepack and Node official document prefer the later one.

Refer to https://nodejs.org/en/learn/command-line/how-to-read-environment-variables-from-nodejs

Which is the standard or recommended file pattern? .env.foo or .foo.env? Corepack and Node official document prefer the later one.

Refer to https://nodejs.org/en/learn/command-line/how-to-read-environment-variables-from-nodejs

.foo.env is the preferred one

A further suggestion:

We should treat .env as a file extension. Therefore, disallowing the files with non .env extension for --env-file will benefit Node community.