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.
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".
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.localhttps://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:
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.
@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.
@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",
@STEVEOO6 thanks, but i preferred not to override next's built-in dotenv, instead i'm using env-cmd.
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.
Most helpful comment
@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.