src: add process.loadEnvFile and util.parseEnv

[anonrig]

Introduces 2 new functions to use the default .env parser.

process.loadEnvFile(path)

• In order to load the .env file in the current directory:

process.loadEnvFile()

• Load a specific path:

process.loadEnvFile('./development.env')

util.parseEnv(content)

• In order to parse an existing string:

assert.deepStrictEqual(require('node:util').parseEnv('HELLO=world'), { HELLO: 'world' });

Fixes #51413
Ref #49148

---

Thank you Sentry for sponsoring this work!

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/startup

[github-actions]

The notable-change PRs with changes that should be highlighted in changelogs. label has been added by @anonrig.

Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section.

[nodejs-github-bot]

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

[aduh95]

Can you please add a test that validates what happens when the .env file defines a NODE_OPTIONS?

[GeoffreyBooth]

I just reviewed the docs, but 👍 to the general idea. Thanks for implementing this.

[targos]

It seems more logical to me to have it on process, since it has direct effect on process.env. An utility function would only return the parsed result without side effects

[anonrig]

It seems more logical to me to have it on process, since it has direct effect on process.env. An utility function would only return the parsed result without side effects

@targos Process is a global variable. Are you suggesting having process.loadEnvFile()?

[targos]

That's what I'm suggesting, yes.

[arthurfiorette]

What about also adding a "register" like import which simply consists of the following file:

import util from 'node:util'
util.loadEnvFile()

which allows it to be used as follows:

import 'node:util/load-env'

Ofc load-env was just a random name I chose. It's similar to how dotenv/register works, which would ease migration to this native node way.

[GeoffreyBooth]

Ofc load-env was just a random name I chose. It’s similar to how dotenv/register works, which would ease migration to this native node way.

I don’t think “be able to load environment variables from a file in a one-liner” is a high priority. I think we should separate out the loading from the parsing, and this should just be parseEnvFile and it can stay on util. This takes care of the other request that someone had, to be able to load multiple files.

import { parseEnvFile } from 'node:util'
import { dev } from './my-environment.js'

const commonVariables = await readFile('.env', 'utf8')
const environmentSpecificVariables = await readFile(`.${dev ? 'dev' : 'prod' }.env`, 'utf8')
const parsedCommonVariables = parseEnvFile(commonVariables)
const parsedEnvironmentSpecificVariables = parseEnvFile(environmentSpecificVariables)
process.env = { ...process.env, ...parsedCommonVariables, ...parsedEnvironmentSpecificVariables }

[MoLow]

LGTM. I agree it makes sense to move to process

[nodejs-github-bot]

Landed in 0056147