Repository navigation
Empty REACT_APP_ env vars in .env.production cannot override its counterpart in .env #4002
Description
Is this a bug report?
Yes.
When an REACT_APP_ environment variable is set in .env, we cannot overwrite it with an empty string.
In our scenario, our app tries to connect to an development API server running on local machine, but in production the static files built with npm build will be served directly with API server. The host name is set through an REACT_APP_ENDPOINT environment variable, with it being localhost in .env and being an empty string in .env.production. However, the empty string somehow cannot override the settings in .env.
In reality I worked-around this by putting REACT_APP_ENDPOINT in .env.development.
Also, for API servers we can also use proxies instead. However, I think it's still a bit counter-intuitive that settings in .env.production cannot override the one in .env. That's why I opened this issue.
Did you try recovering your dependencies?
It's reproducible in fresh install of create-react-app
Which terms did you search for in User Guide?
envthen read through "Adding Custom Environment Variables"
Environment
node -v: v8.9.0npm -v: 5.5.1npm ls react-scripts(if you haven’t ejected): react-scripts@1.1.0
Then, specify:
- Operating system: Mac OSX
Steps to Reproduce
- Create
.envand writeREACT_APP_ENDPOINT=http://localhost:8080 - Create
.env.productionand writeREACT_APP_ENDPOINT= - in
App.jsput:
console.log('ENDPOINT', REACT_APP_ENDPOINT} + '/api');
npm run build- Manually open the built main..js, search for 'ENDPOINT: '
Expected Behavior
Find this in the built js:
console.log('ENDPOINT', '/api');
Actual Behavior
Find this in the built js:
console.log('ENDPOINT', 'http://localhost:8080/api')
Reproducible Demo
Repo
https://github.com/MrOrz/create-react-app-env-override/
Activity
iansu commentedon Feb 9, 2018
This does sound like a bug. I took a quick look at the
dotenvsource and it does allow you to set an empty environment variable. The empty value in.env.productionshould take precedence over the non-empty value in.env.I think the workaround you came up with is a better way to handle this situation anyway but we should still look into what's going on here.
heyimalex commentedon Feb 9, 2018
It looks like this was fixed in dotenv here. So, looks like we need to wait for 5.0 release.
iansu commentedon Feb 9, 2018
Looks like 5.0 was released a couple of weeks ago so we just need to upgrade. Too bad we didn't notice that before the
1.1.1release yesterday. 😞Timer commentedon Feb 9, 2018
Since this is potentially breaking for others who may rely on the behavior it's probably better to do this in 2.x only [
dotenvcalled it a major].iansu commentedon Feb 9, 2018
Makes sense. I've submitted a PR to
nextonly at this point. I won't make one of1.x.gaearon commentedon Feb 10, 2018
The fix will be available in the next 2.x alpha.
#4009 (comment)
bcarroll22 commentedon Jun 12, 2018
Hey everyone, just wanted to point out that I'm still running into this issue. I believe the bug here is actually being introduced by
dotenv-expand. When I take it out, the variable overrides behave correctly, but something in theexpandpackage causes issues that allow empty strings to be overridden.