Ensure Next.js is correctly respecting NODE_ENV

[Timer]

Next.js should unconditionally use NODE_ENV=development and NODE_ENV=production for next dev and next build respectively in the following areas:

• .env.* loading
• Client-side bundle inlining
• Server-render time
• next/babel plugin internal mode (fix(next/babel): read env from caller, not process #20679)
• Webpack mode (fix(next/babel): read env from caller, not process #20679)

The only way to read a "misconfigured" NODE_ENV (e.g. NODE_ENV=staging) should be in next.config.js. This is only allowed for backwards compatibility.

I believe we also have to allow it to override what Babel "env" is loaded. I don't feel strongly about this.

Next 11 should disallow all non-standard values for this and immediately exit. This behavior should be implemented by whatever PR closes this behind a future flag.

---

We also need to fix this message:

warn  - You are using a non-standard "NODE_ENV" value in your environment. This creates inconsistencies in the project and is strongly advised against. Read more: https://err.sh/next.js/non-standard-node-env

[Timer]

Related: #17032 #19001

[flybayer]

[ ] .env.* loading

I believe we should add an alternate way to specify which env files should be loaded, like this:

next dev -e [test|development|production]

[curiousercreative]

@flybayer that would solve my exact frustration. Our application doesn't care about the NODE_ENV, but we need our staging deploys to use non-production constants from a non-production .env file. I'd be careful not to restrict the values that we support for mapping to an env.* file. An obvious omission from your enumerated list is a staging environment, but I'd suggest we do not restrict these values.

[curiousercreative]

Here's a quick and dirty that should allow for DOT_ENV=staging next build to load .env.staging rather than .env.production while preserving prior behavior when DOT_ENV has not been supplied. #26209

[curiousercreative]

@Timer @flybayer @timneutkens thoughts on allowing user to determine which .env override file is loaded? Thoughts on env variable name DOT_ENV as the means for accomplishing this? Should we go even further and allow for a list of .env files to be selected?

[flybayer]

@curiousercreative I've recently opened an extensive RFC here: #25764

[Raynos]

I just tried NODE_ENV=development next build to use the non minified version of react and it refuses to use the non minified version of react.

This magic build into nextjs is incredibly frustration and a terrible user experience.

[bailout00]

Looks like this is still open, and still an issue, causes Error: should not be imported outside of pages/_document.
if NODE_ENV=development when running next build

[hichemfantar]

Looks like this is still open, and still an issue, causes Error: should not be imported outside of pages/_document. if NODE_ENV=development when running next build

does it work when you set it to production?

[christopher-theagen]

#52158

[timeverts]

Looks like this is still open, and still an issue, causes Error: should not be imported outside of pages/_document. if NODE_ENV=development when running next build

I also get this error, only when setting NODE_ENV=development when running next build.

[ChenAlmost]

I solve this problem by add a APP_ENV when I run next build and use dotenv read the .env.* according to the value of APP_ENV in next.config file, overwrite the process.env.*

Here's a quick and dirty that should allow for DOT_ENV=staging next build to load .env.staging rather than .env.production while preserving prior behavior when DOT_ENV has not been supplied. #26209