Discussion regarding the way how @next/env loads environment

[Ashvith10]

Summary

This is regarding how the current @next/env has some issues, and at the same time the headache I had with how there was little to nothing documented on the main webpage - unfortunately, there's no way to do general discussions here, so I've added this to the "Help" category.

The "default" convention of environment variables is:

1. Assuming that environment will always be development by default
2. If provided through NODE_ENV, it can be over-ridden to development (default), production, staging and test

At present, @next/env loads environment variables in a non-conventional way.

next.js/packages/next-env/index.ts

Lines 136 to 146 in 126c226

	const isTest = process.env.NODE_ENV === 'test'
	const mode = isTest ? 'test' : dev ? 'development' : 'production'
	const dotenvFiles = [
	`.env.${mode}.local`,
	// Don't include `.env.local` for `test` environment
	// since normally you expect tests to produce the same
	// results for everyone
	mode !== 'test' && `.env.local`,
	`.env.${mode}`,
	'.env',
	].filter(Boolean) as string[]

The issue with the code is that:

a) Line 136 check if process.env.NODE_ENV is 'test', line 137 sets mode to 'test' if it is 'test' ,and line 143 checks if it is 'test'. isTest and mode is used nowhere in the entire file - all of this could've been done by just removing line 136 and 137, and replacing ${mode} with ${process.env.NODE_ENV}

b) the value of dev will most probably be set to something like:

loadEnvConfig(process.cwd(), process.env.NODE_ENV === 'development')

by making the changes in point (a) and letting next/env do the decision for us by reading the NODE_ENV value, there is no need to check for the same

c) there isn't any way to provide a staging env, the changes provided in point (a) should be able to resolve this

We may also be able to remove dotenv, since NodeJS 20 and onwards supports env natively, and dotenv-expand may be accomplished through destructing.

Additional information

\-

Example

-

[RossMcMillan92]

This seems like a genuine and potentially nasty bug. Can imagine a scenario where someone thinks they're playing with their dev database but they're actually using production and ends up causing costly damage.

The docs clearly state that the .env.* file loaded is based off the current NODE_ENV var but that's not what's happening. There's no mention in the docs of the second dev param that you need to pass.

At least one issue has been created for this, but ignored and auto-closed.