src: return error --env-file if file is missing

[ardinugrxha]

Motivated by #50536

NodeJS currently supports env file parsing. However, in cases where the file is missing, the process continues to execute. Since the env file is a crucial file, I propose that we return an error if the env file is missing. This will prevent errors in the future and allow us to detect them as early as possible.

Testing Scenario:

Given files tree:

└── test/
    ├── hello.js
    └── test.env

run: node --env-file=test.env hello.js
output: it will executed

└── test/
    ├── hello.js
    └── test.env

run: node --env-file=oops.env hello.js
output: node: oops.env not found

└── test/
    ├── hello.js
    └── test.env
    └── test1.env

run: node --env-file=test.env --env-file=test1.env hello.js
output: it will executed

└── test/
    ├── hello.js
    └── test.env
    └── test1.env

run: node --env-file=test.env --env-file=oops.env hello.js
output: node: oops.env not found

[nodejs-github-bot]

Review requested:

• @nodejs/startup

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[ardinugrxha]

Seems several CI have failed even already retrying, is this expected? 🤔

[ardinugrxha]

Seems several CI have failed even already retrying, is this expected? 🤔

Unit testing goes error on Windows, will check later and maybe come back with a new push

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[nodejs-github-bot]

Landed in 996d198

[jmjf]

@ardinugrxha

Is it intended that this change will break existing npm scripts and the CI processes that rely on them?

I have a test script that runs tests with --env-file=.env. The .env file is not checked in to my repo because it contains secrets.

This script worked in CI before 20.11 because CI has env variables set up in the CI environment. Now it fails.

My workaround will be to duplicate the test script without --env-file, but I'm not sure non-major releases in LTS should require workarounds.

[acidoxee]

Hi, I have the same issue as @jmjf. Some of my scripts used --env-file .env as a non-mandatory env injection mechanism, but now after upgrading to Node 20.11.0, all of those scripts break if the file isn't there (which happens mostly in CI). There are workarounds, so I'll get by, but it's quite surprising seeing such a breaking change land in a minor version without warning. This change isn't even mentioned as a notable change in the changelog, it's only listed in the commits.

#50993 seems like a nice alternative that would have been nice to ship at the same time, but it's not there yet. Also, it may have been sweeter to ship it the other way around, like adding a --strict-env-file or something (that breaks if the env file isn't there) instead of changing the current way of working of the --env-file flag in a breaking way.

[anonrig]

@acidoxee This is an experimental feature. Breaking changes are meant to happen.

[jmjf]

Breaking changes in LTS? I guess I misunderstood LTS as being stable. Nevertheless, these cases indicate that there are cases where no env file is reasonable, so maybe this change should be reconsidered.

…

On Sat, Jan 13, 2024, 08:45 Yagiz Nizipli ***@***.***> wrote: @acidoxee <https://github.com/acidoxee> This is an experimental feature. Breaking changes are meant to happen. — Reply to this email directly, view it on GitHub <#50588 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASIV63GFKYX4PAVZQKLSQTYOKFY7AVCNFSM6AAAAAA7AVC2P2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQGQ3DGMBYGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[anonrig]

--env-file=config has a stability index of 1.1 - Active Development. Let's take a look into the stability index (ref: https://nodejs.org/docs/latest/api/documentation.html#stability-index)

Stability: 1 - Experimental. The feature is not subject to [semantic versioning](https://semver.org/) rules. Non-backward compatible changes or removal may occur in any future release. Use of the feature is not recommended in production environments.
Experimental features are subdivided into stages:

1.0 - Early development. Experimental features at this stage are unfinished and subject to substantial change.
1.1 - Active development. Experimental features at this stage are nearing minimum viability.
1.2 - Release candidate. Experimental features at this stage are hopefully ready to become stable. No further breaking changes are anticipated but may still occur in response to user feedback. We encourage user testing and feedback so that we can know that this feature is ready to be marked as stable.

[acidoxee]

@acidoxee This is an experimental feature. Breaking changes are meant to happen.

Oh, my apologies then, I was pretty sure it was considered stable already for some reason. A notable change in the changelog would still have been nice, but you're 100% right to do breaking changes if it's experimental and if that leads to a better, thoughtful API in the end 👍

[BoscoDomingo]

Hi, sorry for the noise this may cause:

Are you considering adding the optionality back? It'd be nice to see a --optional-env-file. Just now I was switching from dotenv-cli to the native loader, and having to create a duplicate script without the --env-file is not the best experience.

I can also try to do it myself, but I've 0 familiarity with Node's codebase and C++, when it might be an easy task for anyone more knowledgeable than me.

Edit: There's already a Feature Request for this, #50993, and a related issue #51451