Review requested:

• @nodejs/config

Codecov Report

❌ Patch coverage is 84.61538% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.05%. Comparing base (c8d5b39) to head (6d075c6).
⚠️ Report is 443 commits behind head on main.

@@            Coverage Diff             @@
##             main   #59125      +/-   ##
==========================================
+ Coverage   90.03%   90.05%   +0.02%     
==========================================
  Files         648      648              
  Lines      190967   190984      +17     
  Branches    37425    37443      +18     
==========================================
+ Hits       171931   171988      +57     
+ Misses      11665    11625      -40     
  Partials     7371     7371              

... and 40 files with indirect coverage changes

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

We already have this logic in place for process.loadEnvFile so I figured that it could make sense to just repurpose it also provide a user facing function.

I don't get it, how is process.loadEnvFile not user facing?

We already have this logic in place for process.loadEnvFile so I figured that it could make sense to just repurpose it also provide a user facing function.

I don't get it, how is process.loadEnvFile not user facing?

Sorry, yeah my wording there is misleading, yes, of course process.loadEnvFile is user facing, my idea here was to add another function (still user facing) that is a generalization of process.loadEnvFile.

Basically process.loadEnvFile loads a dotenv file onto an object, and that object is (necessarily) process.env, so I was thinking, wouldn't it make more sense to have a loadEnvFile utility that allows the user to load a dotenv file onto any object? (and that object could even be process.env itself, making process.loadEnvFile not really necessary anymore).

My idea here was related on having a counterpart for parseEnv, there being a utility for parsing a dotenv content but not one for loading that from a file feels to me like a missing API.

I was also thinking of maybe trying to take this even a step further and have a node:dotenv module where these two functions plus any potential new dotenv function could live (like for serializing an object into a dotenv file, of functions for validating dotenv content, etc...), this could be a nice little new module that gives users a bunch of useful tooling for dealing with dotenv files 🙂 (I am thinking of also tooling authors that might want to use node for doing more complex dotenv operations)

It seems redundant when you can basically do the same with util.parseEnv(fs.readFileSync('.env', 'utf8')).

It seems redundant when you can basically do the same with util.parseEnv(fs.readFileSync('.env', 'utf8')).

Mh... under that argument I'd also say that process.loadEnvFile is also redundant since you can do the same with:

Object.assign(process.env, util.parseEnv(fs.readFileSync('.env', 'utf8')))

no? 🤔

Wasn't util.parseEnv introduced because process.loadEnvFile was too narrow?

Wasn't util.parseEnv introduced because process.loadEnvFile was too narrow?

I don't know to be honest... I just saw that they were introduced together (#51476)

See #51476 (comment)

Closing since I don't think we're going to go with this API due to the conversation above ( 🥹 )