util: add loadEnvFile utility

[dario-piotrowicz]

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.

This function is the analogous of util.parseEnv but for files.

[nodejs-github-bot]

Review requested:

• @nodejs/config

[dario-piotrowicz]

this is a breaking change, but I hope it's fine given that dotenv is experimental (and I don't imagine many developers relying on this behavior? 🤔)

I am also not sure about the rational, personally if a new env file is loaded onto process.env I would expect that it would override whatever else is there 🤔

[dario-piotrowicz]

If this is a problem I can keep the existing behavior.

Since I am thinking of making more changes in this space, to avoid churn and I would prefer this PR not to be a semver-major one if possible.

[dario-piotrowicz]

Given how trivial it is to load a .env file onto process.env I even wonder if we could deprecate/remove process.loadEnvFile.

To me personally it feels much clearer to have this sort of operation more manual and have the user load their .env files withloadEnvFile and then use the values to populate process.env themselves if and how they want (with any overriding, filtering, etc. logic).

[codecov]

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.

Files with missing lines	Patch %	Lines
src/node_util.cc	69.23%	5 Missing and 3 partials ⚠️

Additional details and impacted files

@@            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              

Files with missing lines	Coverage Δ
lib/internal/process/per_thread.js	99.27% <100.00%> (-0.19%)	⬇️
lib/util.js	97.83% <100.00%> (+0.08%)	⬆️
src/node_process.h	25.00% <ø> (ø)
src/node_process_methods.cc	88.55% <ø> (+0.74%)	⬆️
src/node_util.cc	80.74% <69.23%> (-0.93%)	⬇️

... and 40 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ 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.

[aduh95]

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?

[dario-piotrowicz]

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).

[dario-piotrowicz]

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)

[targos]

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

[dario-piotrowicz]

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? 🤔

[aduh95]

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

[dario-piotrowicz]

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)

[targos]

See #51476 (comment)

[dario-piotrowicz]

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