-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow environment variable overrides #4570
Comments
Hey @tremby, Can you tell me if I've understood your use case correctly? You've got these three environments: development environment
.env.development file:
staging environment
.env.production file:
production environment
.env.production file:
But in the staging environment you want |
That's right. |
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
|
There's some new docs on handling additional environments: https://www.gatsbyjs.org/docs/environment-variables/#additional-environments-staging-test-etc Added via #4858 |
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. |
@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) |
@m-allanson Hi. Thanks |
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 or have a build script in package.json that is like:
gets a bit ugly if there are tons of variables though |
@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? |
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 👍 |
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 👍 |
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 For example, let's say I have
and
Let's say I build with I would expect grepping |
@jgonera I encountered that issue on 2.1.31, updated to 2.13.52 and it works fine, you might want to try that. |
I have also just encountered this issue and seem to get an error when trying to upgrade gatsby to |
For example, let's say I have .env.development with the following content: MY_VAR=hello-dev MY_VAR=hello-prod 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). |
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 beproduction
.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 withGATSBY_
.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.The text was updated successfully, but these errors were encountered: