Allow environment variable overrides

[tremby]

I'm aware that Gatsby will pass in any GATSBY_* environment variables. But this doesn't help in my current use case.

I have three environments: development, staging, and production.

Staging should be a production-like build, and therefore NODE_ENV needs to be production.

But that means I can't load in the environment variables I need (which are different from the production ones) from .env.staging, since only .env.$NODE_ENV is loaded.

I also can't override for example API_URL because it doesn't start with GATSBY_.

Perhaps it would make sense to allow, in addition to GATSBY_*, any env vars found in the .env file, and if any are found, let the env vars take precedence? Alternatively, allow somewhere to configure a whilelist of such env var names?

By the way, my current workaround is to consume these vars in my code as process.env.GATSBY_API_KEY || process.env.API_KEY but this seems ugly and verbose to me.

[m-allanson]

Hey @tremby, Can you tell me if I've understood your use case correctly? You've got these three environments:

development environment

NODE_ENV=development

.env.development file:

API_KEY = devApiKey

staging environment

NODE_ENV=production

.env.production file:

API_KEY=prodApiKey

production environment

NODE_ENV=production

.env.production file:

API_KEY=prodApiKey

But in the staging environment you want API_KEY to be something like API_KEY=stageApiKey?

[tremby]

That's right.

[camsjams]

I have the same need for this use, I've used Gatsby in production for about a year now and have different things like API keys, account Ids for metrics, and a few other items that are environment specific.

For me its more complex than just configs per environment, as I also need to set NODE_ENV=production to have minified builds:

DEV
  accountId: dev_account1
  NODE_ENV=production
QA
  accountId: qa_account1
  NODE_ENV=production
STAGING
  accountId: stg_account1
  NODE_ENV=production
PRODUCTION
  accountId: prod_account1
  NODE_ENV=production

[m-allanson]

There's some new docs on handling additional environments: https://www.gatsbyjs.org/docs/environment-variables/#additional-environments-staging-test-etc

Added via https://github.com/gatsbyjs/gatsby/pull/4858/

[alvis]

The ability to overwrite env vars is needed I think. Recently I'm facing a similar problem upon deploying an A/B test. I was setting up multiple sites with different titles and slogans, deploying via netlify. While I can set up multiple .envs, I found it more easy to manage via just changing the environment variables supplied to netlify.

[camsjams]

@m-allanson Thanks for this update - this appears to be exactly what I need! (I somehow missed the notification from 15 days ago so also thanks to @alvis for bumping)

[ThiagoMiranda]

@m-allanson Hi. Following the docs about handling additional staging environments I can only add this "per file"? For example: I have a .env.staging file with a diferent base_api_url then the production one So I´ve added the snippet code in my gatsby-config.js file but it only works on the gatsby-config.js file itself not in the actual file that I use the base_api_url inside my src folder. How can I "overwrite" it to respect my .env.staging variables in all files not just the ones that´ve added the dotenv code?

Thanks

[mbergeronupgrade]

Same setup of stage, dev, production environments with different env files for all 3. However only the .env.production is used when outputting minified builds, so the other envs.

Fix for now is having the build machine set the environment variables pre-build instead of counting on NODE_ENV for dotenv to load the proper variables file. This is also what is recommended to do by The Twelve Factor App.

or have a build script in package.json that is like:

"build:dev": "NODE_ENV=production GATSBY_SOME_VAR=somevalue gatsby build"

gets a bit ugly if there are tons of variables though

[kakadiadarpan]

@ThiagoMiranda can you provide a sample reproduction repo showing your use case? That would make it much easier to help you out.

@mbergeronupgrade did you went through the link shared by @m-allanson?

[kakadiadarpan]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub issues, we have to clean some of the old issues as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Gatsby version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[kakadiadarpan]

This issue is being closed because there hasn't been any activity for at least 30 days. Feel free to open a new one if you still experience this problem 👍

[jgonera]

Confirming that what @ThiagoMiranda and @mbergeronupgrade mentioned is still an issue with Gatsby 2.4.3. I don't have a repro repo but it seems that files in src/ never pick up variables loaded in gatsby-config.js from .env.${activeEnv}.

For example, let's say I have .env.development with the following content:

MY_VAR=hello-dev

and .env.production with:

MY_VAR=hello-prod

Let's say I build with GATSBY_ACTIVE_ENV=development npm run build and I have src/components/Something.tsx which uses process.env.MY_VAR to render something.

I would expect grepping public/ for hello-prod to yield no results and grepping for hello-dev to show the rendered component, but it's not the case (it's the other way round).

[Ronserruya]

@jgonera I encountered that issue on 2.1.31, updated to 2.13.52 and it works fine, you might want to try that.

[supert56]

I have also just encountered this issue and seem to get an error when trying to upgrade gatsby to 2.13.52 - sharp.node requires version 6001.0.0 or later, but libglib-2.0.dylib provides version 5801.0.0

[sumitsg10]

For example, let's say I have .env.development with the following content:

MY_VAR=hello-dev and .env.production with:

MY_VAR=hello-prod Let's say I build with GATSBY_ACTIVE_ENV=development npm run build and I have src/components/Something.tsx which uses process.env.MY_VAR to render something.

I would expect grepping public/ for hello-prod to yield no results and grepping for hello-dev to show the rendered component, but it's not the case (it's the other way round).