Add support for custom environments (Next 9.4)

[avxkim]

Feature request

Is your feature request related to a problem? Please describe.

Currently, built-in environments allows only .env.development and .env.production environments, so when you run yarn dev it uses .env.development or .env.local and when you do yarn build, then yarn start it uses .env.production environment. But there's no way to use a staging environment for example, like .env.staging, there's no way to run app with staging environment, if we try to NODE_ENV=staging yarn build && yarn start we get an error: "https://github.com/zeit/next.js/blob/master/errors/non-standard-node-env.md", and it won't have effect, because NODE_ENV would be production anyway, it's being overwritten.

Describe the solution you'd like

There should be a way to set environment when you run your app, like NODE_ENV=staging/prestaging yarn build && yarn start, etc. In CRA i use it this way:

"build:staging": "env-cmd -f .env.staging yarn build",
"build:prestaging": "env-cmd -f .env.prestaging yarn build"

Would be nice to have the same, but built-in in Next.

PS

"build:staging": "env-cmd -f .env.staging yarn build && yarn start" this actually works with Next either, though NODE_ENV would be set to "production".

[timneutkens]

We already give you flexibility to choose from 8 different files, which should be enough:

• .env
• .env.local
• .env.development
• .env.development.local
• .env.test
• .env.test.local
• .env.production
• .env.production.local

https://nextjs.org/docs/basic-features/environment-variables#exposing-environment-variables

This has been the standardized way that people load .env files for a long time and has prior art:

• Rails - https://github.com/bkeepers/dotenv
• Create React App - https://create-react-app.dev/docs/adding-custom-environment-variables/

Hence why I don't think introducing even more ways to load .env files is a feasible idea. Supporting 8 different files was already a stretch but it was what's mostly supported as said.

[avxkim]

@timneutkens my point is, i want to have multiple production builds, but with different environment variables (different .env.[environment] files) and i can accomplish this with env-cmd, but would be nicer if there was a built-in way to choose a certain .env file when you build/run your app.

For example, to use test environment, you launch your app NODE_ENV=test next build && next start, i thought there would be something similar to use our custom .env.somename files.

[STEVEOO6]

@webcoderkz I use the dotenv library and have a configuration that allows me to specify the environment variable file to use via the command line (using another environment variable)

Is something like the following what you're referring to?

example next.config.js

const dotenv = require('dotenv')
dotenv.config({ path: process.env.DOT_ENV_FILE || '.dev' })

module.exports = {
  env: {
    BUILD_VERSION: process.env.BUILD_VERSION,
  },
  serverRuntimeConfig: {
    // Will only be available on the server side
    API_HOST_SERVER: process.env.API_HOST_SERVER
  },
  publicRuntimeConfig: {
    // Will be available on both server and client
    API_HOST_CLIENT: process.env.API_HOST_CLIENT,
    STRIPE_PUBLIC_KEY: process.env.STRIPE_PUBLIC_KEY,
    GOOGLE_MAPS_PLACES_API_KEY: process.env.GOOGLE_MAPS_PLACES_API_KEY,
    ENV: process.env.NODE_ENV
  }
}

example package.json scripts:

"start-prod-a": "NODE_ENV=.prod_a node server.js",
"start-prod-b": "NODE_ENV=.prod_b node server.js",

[avxkim]

@STEVEOO6 thanks, but i preferred not to override next's built-in dotenv, instead i'm using env-cmd.

[aasili-shoprunner]

Is @STEVEOO6 solution the only way around this? It's pretty crazy to me that NODE_ENV=development npm run build would create a production build regardless of the NODE_ENV being set and regardless of the .env defined in the app.

[lakshay-shoprunner]

#12077

[evangow]

I would say that .env.staging is probably a common enough use-case that it should be supported out-of-the-box

[nitaking]

.env.stagingはおそらく十分に一般的なユースケースであるため、すぐにサポートする必要があります。

+1

[Duder-onomy]

I honestly don't understand this restriction.
Seems like a mistake in the framework.
I hope Next fixes this before some bloggers find out about this error. Coupling the next 'commands' with environment configuration is a mistake. I should be able to, out of the box, produce a 'build + export' using a 'staging' environment (or any other environment I want). I should not need to override the built-in configuration settings to do something so simple.

There is a TON of prior art on this. Search for almost any deployment strategy and they will point to multiple different types of 'production' builds.

[andrewmclagan]

The issue with most of these answers is they go against the principal of "build once run everywhere", in reality most of us are using this technique build and run with Docker containers. It's not possible to have multiple build commands like this, and it would be bad practice.

Better have your environment available at runtime. We created a package that allows next static optimisation and still have runtime env vars via window.__ENV

https://github.com/andrewmclagan/react-env

This works by generating an environment config object at runtime from whitelisted env vars:

{
  ...
  "scripts": {
    "dev": "react-env -key APP_ENV -- next dev", // where .env.${APP_ENV}
    "start": "react-env -key APP_ENV -- next start" // where .env.${APP_ENV}
  }
  ...
}

[flybayer]

I've posted a new RFC to fix issues with loading .env.X files: #25764

Please review and give any feedback you may have

[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.