Environment variables are not captured utilizing NODE_ENV in Webpack

[DSchau]

Description

Environment variables (captured in .env.ENVIRONMENT, e.g. .env.staging) do not get exposed correctly to the code that gets bundled with Webpack, e.g. the client-side, non-Node code.

We can see this by walking through the build process:

1. Add a script, build:staging

   {
     "scripts": {
       "build:staging": "cross-env NODE_ENV=staging npm run build"
     }
   }

2. gatsby build is kicked off via the CLI here

   • This explicitly sets NODE_ENV=production, therefore ignoring any overrides from the user

3. Environment variables are sourced via Webpack here

   • This will always be production; it's not possible to override this since it's set and overwritten early in the build via the CLI

Steps to reproduce

1. Clone this repo
2. Run yarn or npm install
3. Run yarn build:staging
4. The environment variable API_KEY in .env.staging should be present in the built code

Expected result

The environment variable API_KEY from .env.staging should be present in public/index.html

Actual result

The environment variable API_KEY from .env.production is used.

The Fix

I don't believe we can overwrite NODE_ENV as production is checked fairly often in various plugins/APIs/etc. Using process.env.NODE_ENV = process.env.NODE_ENV || 'production' in gatsby-cli seems to break the build.

As such - I think there are two things that we should do here to remediate the issue.

1. Tweak this code to check for an environment override outside of NODE_ENV
   • Perhaps ACTIVE_ENV as we document here
2. Tweak any documentation to make it clear that this new environment variable must be used if you want to use a separate .env file for a "production" build

I don't love the indirection and extra steps here--but not sure I see a better solution off hand. Opinions more than welcome here!

cc @xjamundx

[KyleAMathews]

So the problem is how to set environment variables for staging builds?

[DSchau]

Correct. Basically we can’t use NODE_ENV because that gets set by the build
command explicitly. Another solution would be to move off of NODE_ENV for gatsby internals and explicitly prefix our internal variables. Both seem to solve the problem.

[KyleAMathews]

But we can't use NODE_ENV right because webpack/babel/terser need it set to production?

[DanielRuf]

webpack/babel/terser need it set to production?

Not really as webpack 4.x introduced the mode flag.

See https://webpack.js.org/guides/production/#specify-the-mode

Internally the mode for webpack builds can be changed / set depending on the setup / script

[KyleAMathews]

Ah cool. Yeah setting NODE_ENV seems ideal as it's widely used for this sort of thing.

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[gatsbot]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

Thanks again for being part of the Gatsby community!

[ankesh7]

Any updates on this? I am running into an issue where I have multiple environments and only one needs to have the Google Tag Manager injected. I am using the gatsby-google-tagmanager plugin and every time i run ACTIVE_ENV=something yarn gatsby build, NODE_ENV is always set to production and it skews my analytics.