Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Document multiple build environments via `env-cmd`

See original GitHub issue

The term “development environment”, “test environment” and “production environment” is used differently across the contexts and sometimes cause confusion for users.

  • create-react-app defines the environment name by the state of app code build: “development” means the code is not minified and run in live reload mode on local machines, “test” means the code is executing in unit test process, “production” means the code is minified and optimized with source map. I’ll call this “development build”, “test build” and “production build”.

  • Mean while, in large portion of the software industry, these terms are used differently:


In the diagram above, I’ll call them deploy environment, each deploy environment is a set of all the services that linked and worked with each other in an isolated place (servers/VPN).

“Frontend” is where create-react-app lives, and this all run “production build” of the app, which means the code is minified and optimized.

The problem

Regarding this document:

  • NODE_ENV always resolves to production when built with yarn build, even if we try to run NODE_ENV=staging yarn build.
  • There is no effective way to define different environment variables for each deploy environments. This is a real need.
  • There is no or very little benefit to define different environment variables for development build and production build, most of the time it is the same.

What I have been doing to resolve this

  • Put all the environment variables in source code and use domain name to identify the deployment environment the app is running. This reveals environment variables of all deployment environments, not so good.
  • or
  • Having different package.json scripts to build for different deployment environments: yarn build-staging, yarn build-production,… In the script, it creates .env file according the deployment environment and build. Ex: mv env/staging.env ./.env && yarn build.
  • or
  • On each deployment environment I setup a mini server that hosts an API endpoint and return environment variables for that deployment environment. (ex:

Better way?

What is the best practice here? Have anyone of you run into this problem? How did you do it? Should create-react-app do something about this? Please share, thanks!

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:10
  • Comments:7 (3 by maintainers)

github_iconTop GitHub Comments

Timercommented, Feb 24, 2018

The easiest way to achieve this is via .env files, injecting each variable you’d like to use in your app, most close to your second solution.

Instead, create one for each environment.




Then you can just add some extra scripts in your package.json:

  "scripts": {
    "build:staging": "env-cmd .env.staging yarn build",
    "build:qa": "env-cmd yarn build"

In this scenario, .env.production would only be used for fallback if a variable isn’t specified in .env.staging or

MilllerTimecommented, Feb 24, 2018

You described the situation well 🙂

The default use of NODE_ENV is intentional and is solely used to distinguish between local development builds, unit tests, and optimized production builds. You can think of 'production' as a generic “distribution” build, not necessarily a build literally destined for a public-facing production server.

As you mentioned, it is common to have a few types of server environments for an application. These should all run the optimized NODE_ENV=production build, so that you can test your app with production-level performance. In order to programmatically differentiate between environments at runtime, you’ll need to use a different environment variable, something other than NODE_ENV.

Create-react-app mandates that you prefix any custom environment variables with REACT_APP_. You can set custom prefixed environment variables from a CLI, see this section of the readme. In Bash for example, you could run:

REACT_APP_DIST_ENV=staging yarn build

You can access the variable in your app with process.env.REACT_APP_DIST_ENV. For example:

if (process.env.REACT_APP_DIST_ENV === 'staging') {

I haven’t personally tried this with create-react-app, but check out the cross-env package. It allows setting environment variables in a cross-platform manner. You could then simplify your package.json scripts to something like this:

"build:staging": "cross-env REACT_APP_DIST_ENV=staging && yarn build"

Then run yarn build:staging on any machine to compile an optimized build ready to be deployed on a staging server.

Read more comments on GitHub >

github_iconTop Results From Across the Web

How To Use Environment Files with env-cmd
Learn how to add handle environment variables with the env-cmd package.
Read more >
Using multiple .env files.
One solution is to have multiple .env files which each represent different environments. In practice this means you create a file for each...
Read more >
Environment Variables: .env files and env-cmd
Environment Variables are variables that are set by the Operating System. They are decoupled from application logic. They can be accessed from ...
Read more >
Multiple environments in Create React App
We could solve this by using a single .env file but, each time you ... For QA and Production build replace the command...
Read more >
Best way to manage env variables for multiple environments
I am using env-cmd to hook my .env files to my tasks. ... react-scripts build", "build:test": "env-cmd -f .env.test npm run-script build ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found