NODE_ENV=development next build fails on static 404 and 500 pages

[mercteil]

What version of Next.js are you using?

10.2.3

What version of Node.js are you using?

14+

What browser are you using?

Chrome

What operating system are you using?

macOs

How are you deploying your application?

next start

Describe the Bug

After updating from 10.1.3 to 10.2.3 and script execution NODE_ENV=development npm run build (=> next build) the following error appears:

info  - Creating an optimized production build
info  - Compiled successfully
info  - Collecting page data
[==  ] info  - Generating static pages (0/4)

Error occurred prerendering page "/en/404". Read more: https://nextjs.org/docs/messages/prerender-error
TypeError: Cannot assign to read only property 'children' of object '#<Object>'

(...)

> Build error occurred
Error: Export encountered errors on following paths:
	/de/404
	/de/500
	/en/404
	/en/500

When executing the same script with NODE_ENV=production npm run build everything works as expected.

Downgrading next to 10.1.3 resolves the issue.

Why do I need to set NODE_ENV? Several configuration options depend on the NODE_ENV. For exmaple in development a different backend url and DB is being accessed etc.

Expected Behavior

NODE_ENV=development next build works as it did in 10.1.3

To Reproduce

NODE_ENV=development next build

Building static 404 and 500 pages fails...

[mattcarlotta]

Related to #19046. Currently, Next relies upon NODE_ENV to be production when building.

[mercteil]

Thanks.

The related warn link below was never shown, probably a good idea to show it to guide the users:

https://nextjs.org/docs/messages/non-standard-node-env

[mattcarlotta]

Thanks.

The related warn link below was never shown, probably a good idea to show it to guide the users:

https://nextjs.org/docs/messages/non-standard-node-env

I found some time to dive into the source and Next is only checking for non-standard NODE_ENV values. So technically, you can pass NODE_ENV=development with yarn build and no warning/error will be shown since NODE_ENV=development is a valid environment. It looks like #19046 will partially address this some time in the future. However, I strongly believe overriding NODE_ENV to be anti-pattern since quite a bit of 3rd party dependencies (like React) rely upon NODE_ENV to determine which bundle version (development or production) to import. This also affects how Babel and Webpack transpiles/compiles/handles assets.

So... since you're trying to import Envs based upon NODE_ENV, and the Next team hasn't allowed developers to control how and which Envs are loaded, I would suggest an alternative solution instead.

Click to expand alternative solution

I've developed a package for loading Envs called @noshot/env, which I have been using for my personal and professional projects for the past 7 months. This package operates similar to dotenv/dotenv-config -- which is what @next/env uses; however, my package is a bit more optimized and, more importantly, flexible.

1.) Install the package: npm i @noshot/env or yarn add @noshot/env

2.) Create an env.config.json file in your projects root directory and add paths properties for environments. These paths refer to the .env.* files you'd like to load for the environment. These environments can be named anything you'd like and you can import one or many .env.* files:

env.config.json (for a complete list of allowed properties see config arguments)

{
  "development": {
    "paths": [".env", ".env.development", ".env.local", ".env.development.local"],
    "debug": true
  },
  "staging": {
    "paths": [".env.staging"],
    "debug": true
  }
}

3.) Then. utilize LOAD_CONFIG with script preloading to load a specific configuration according to the specified environment:

package.json

{
  "scripts": {
    "dev": "LOAD_CONFIG=development NODE_OPTIONS='-r @noshot/env' next dev",
    "staging": "LOAD_CONFIG=staging NODE_OPTIONS='-r @noshot/env' next build"
  },
  "dependencies": {
    "snackables": "^3.x.x"
  }
}

And that's it. The package will load the .env.* files into process.env before Next loads! You won't/shouldn't need to override NODE_ENV.

There's only one potential catch: Next will still attempt to load the standard .env.* files according to NODE_ENV during process load up. So if you don't want a specific Env to be loaded, then either rename the .env.* files differently from these or make sure the Env variables overlap -- Next checks if process.env.[ENV] has a value and will skip assigning it a value if it's already defined.

If you're not interested in using the alternative solution, then you should submit an RFC for controlling how/which .env.* files are loaded. However, from using Next for the past 2 years, I don't expect this will gain much traction/adoption in the near future -- mostly to do with developers potentially loading Envs that may override/conflict with Next internals and/or the Webpack configuration.

[flybayer]

I'm also having this bug.

I've opened an RFC for a proper solution here: #25764

[balazsorban44]

Could not reproduce this.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.