Description
Describe the bug
Variables like REACT_APP_FOO
are hard-baked into the code if they were present in the environment during build-time. Referencing a variable that did not exist during build time results in rather useless code that cannot be minified:
process.env.REACT_APP_FOO
->
Object({
NODE_ENV: "production",
PUBLIC_URL: "",
WDS_SOCKET_HOST: void 0,
WDS_SOCKET_PATH: void 0,
WDS_SOCKET_PORT: void 0
}).REACT_APP_FOO
This will neither cause an error, not is it minified into a constant expression.
Full example further below.
Did you try recovering your dependencies?
Problem is reproducible on a fresh install.
> npm --version: 6.14.4
Which terms did you search for in User Guide?
This behaviour is not documented on
https://create-react-app.dev/docs/adding-custom-environment-variables/
Environment
Environment Info:
current version of create-react-app: 3.4.1
[Tested on multiple systems, everything else is irrelevant]
Steps to reproduce
> npx create-react-app test
> cd test
> $EDITOR src/index.js
index.js:
if (process.env.REACT_APP_FOO) {
console.log('Foo is enabled');
}
else {
console.log('Foo is disabled');
}
> npm run build
> cat build/static/js/main*.js
main*.js (prettified):
(this.webpackJsonptest = this.webpackJsonptest || []).push([
[0],
[function(o, s, e) {
o.exports = e(1)
}, function(o, s) {
Object({
NODE_ENV: "production",
PUBLIC_URL: "",
WDS_SOCKET_HOST: void 0,
WDS_SOCKET_PATH: void 0,
WDS_SOCKET_PORT: void 0
}).REACT_APP_FOO ? console.log("Foo is enabled") : console.log("Foo is disabled")
}],
[
[0, 1]
]
]);
Expected behavior
- Preferred: the build emits a warning or an error when referencing a missing variable. It's most likely either a typo in the variable name, or a broken build configuration.
- Alternatively, the variable is replaced with
undefined
orvoid 0
or''
or some other sensible default value. - Alternatively, this behaviour is at least documented with a warning on the corresponding page.
The workaround is to define a default value for every used variable in .env
and commit the file, but that doesn't protect against mistyped identifiers in the code.
Actual behavior
See above for actual output. The output contains both '"Foo is enabled"'
and "Foo is disabled"
, even though one of them is dead code.
Reproducible demo
See above.
I am not sure how best to resolve the issue.
Replacing with undefined
or ''
isn't easy:
- It's not a bug in
terser
- the code could evaluate to something other thanundefined
if someone setsObject.prototype.REACT_APP_FOO
, soterser
is not allowed to minify here. Playing around with terser's repl, I was unable to find a different construct forprocess.env
that would allow minification here. - webpack's
DefinePlugin
does not allow regexps for replacements; substitutingREACT_APP_.*
is not possible.
Emitting an error isn't easy:
- scanning the build output for remaining
process.env.REACT_APP_
won't work, and scanning for the whole code snippet above seems really fragile.
This could be solved by moving the replacement logic from DefinePlugin
into a custom babel plugin (similar to this one). Considering that cra only supports replacing with strings, and not with arbitrary javascript code, that might work. Is babel guaranteed to be run on every source file, including typescript?
If all else fails, I think it deserves at least a warning in the documentation.
Activity
abumalick commentedon May 5, 2020
I pushed a repo that is showing this behavior here:
https://github.com/abumalick/react_app_env_variables
cauthmann commentedon May 5, 2020
@abumalick: That looks like a different issue. I'm not concerned that a list of ENV variables appears in the output - it's likely intended behaviour to account for code like:
Those variables shouldn't contain anything sensitive, and I'm sure some code somewhere relies on this working.
What concerns me (and what I consider a bug) is that referencing a variable that wasn't defined does not result in a constant expression. If env vars are used for feature gating, then this will prevent dead code elimination of the gated features.
As you can see above, both
"Foo is enabled"
and"Foo is disabled"
appear in the output; both branches would presumably contain a lot of code, and one of them is dead code.I've edited the issue to clarify.
dburrows commentedon Jun 2, 2020
Ran across this today and it's hugely annoying - i'm trying to include some debug code in a specific build but this bug causes it to still be included if the env var isn't set which is the opposite of the expected behaviour.
I would expect this to "fail safe", it's a potential footgun for devs.
cauthmann commentedon Jun 3, 2020
I believe the most pragmatic way to fix this is to create a new eslint rule, similar to
no-process-env
(docs, source), except with a whitelist of allowed values. Ideally this should warn in dev, but error on production builds.Implementing that is on my list of things to do when I get bored, but as you can see it hasn't reached the top yet.
johnlobster commentedon Jun 19, 2020
Saw the same thing, I think a note in documentation is a good start, and urgent.
In my case, the code made it into the browser code and then threw a type error because process.env.REACT_APP_VAR didn't exist. Not my favorite javascript feature
I agree that there should be a reasonable default, but I can't think of simple way. There has to be a single source of truth somewhere
I think that the underlying thought behind the documentation is confusing
Environment files are used for
create_react_app creates browser code. If you need a secret, to access a maps api for instance, there is no way to hide that secret.
So passing variables into create-react-app through the
. env
file is probably the wrong approach anyway, particularly if you are developing a full stack app in the same directory where you really do need to pass secrets. This is where the documentation is confused. It says to check in the.env
file.johnlobster commentedon Jun 19, 2020
A solution
cra-cross-env
that reads "cra-env-defaults" sets those environment variables or according to its argumentsCan be used in package.json scripts
I already use
cross-env
in this waydimaqq commentedon Jun 22, 2020
I think this also affects 3rd party libraries, e.g. styled-components/styled-components#3166
stale commentedon Jul 25, 2020
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
dimaqq commentedon Jul 27, 2020
Here's some recent activity for you, you bot! 😆
Kudo commentedon Jul 28, 2020
I also had this problem today.
The final solution is pretty much like @johnlobster did.
But simply adding a default
REACT_APP_FOO
in .env, so that DefinePlugin could replace the variable as constant.echo "REACT_APP_FOO=false" >> .env
In such case, the if statement should rewrite as
if (process.env.REACT_APP_FOO === 'true') {
Details
But not for this:
So we should try to make the code block like the previous one.
DefinePlugin will replace some variables as constants.
From
if (process.env.REACT_FOO === 'true')
toif ('false' === 'true')
Create React App will pass REACT_APP_* from .env to DefinePlugin.
johnlobster commentedon Aug 23, 2020
I have updated the environment variables documentation
cross-env
for setting environment variablesPlease could you take a look ? I would really appreciate some feedback. I moved quite a lot of the documentation around because I thought it had been added to in an inconsistent way
Clearly, this doesn't close this issue, but should stop people falling into the same hole that we did
If you wish to edit my version, I can add you as collaborator to my fork
My fork is at
https://github.com/johnlobster/create-react-app/tree/jw-env-vars
Edited file at
https://github.com/johnlobster/create-react-app/blob/jw-env-vars/docusaurus/docs/adding-custom-environment-variables.md
I deployed the docusaurus build on Netlify and you can find the built documentation at
https://eloquent-hermann-c200a6.netlify.app/docs/adding-custom-environment-variables
stale commentedon Oct 4, 2020
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
stale commentedon Oct 12, 2020
This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.
idler8 commentedon Jan 18, 2022
In a server environment,
process.env
will be used as a wholeIn a browser environment,
process.env.${key}
is used alone for part of the logicWe should distinguish the usage of this part in two contexts
xMartin commentedon Dec 2, 2022
Still an issue with the latest version.