Usage produces fatal error when .env file defines a variable with same name as expanded variable.
atljoseph opened this issue · comments
When I have a .env file like this, everything works fine:
MY_VAR_1=$MY_VAR
But this breaks:
MY_VAR_1=$MY_VAR
MY_VAR_2=$MY_VAR_2
This line causes the breakage:
MY_VAR_2=$MY_VAR_2
Somehow the library cannot handle this situation.
Error produced:
/Users/<REDACTED>/flourish-node-api/node_modules/dotenv-expand/lib/main.js:6
return matches.reduce(function (newEnv, match, index) {
^
RangeError: Maximum call stack size exceeded
at RegExp.exec (<anonymous>)
at /Users/<REDACTED>/flourish-node-api/node_modules/dotenv-expand/lib/main.js:7:54
at Array.reduce (<anonymous>)
at _interpolate (/Users/<REDACTED>/flourish-node-api/node_modules/dotenv-expand/lib/main.js:6:18)
at /Users/<REDACTED>/flourish-node-api/node_modules/dotenv-expand/lib/main.js:36:15
at Array.reduce (<anonymous>)
at _interpolate (/Users/<REDACTED>/flourish-node-api/node_modules/dotenv-expand/lib/main.js:6:18)
at /Users/<REDACTED>/flourish-node-api/node_modules/dotenv-expand/lib/main.js:36:15
at Array.reduce (<anonymous>)
at _interpolate (/Users/<REDACTED>/flourish-node-api/node_modules/dotenv-expand/lib/main.js:6:18)
Someone has already faced this issue and documented it somewhat:
https://stackoverflow.com/questions/49287598/maximum-call-stack-size-exceeded-from-dotenv-expand-on-circleci-using-react
You might ask the question: Why?
- To that I would respond: Why not? Why does it matter how people use it?
- And I would add: It is a form of documentation, in case other developers use different variable names to expand than me.
- Pretty please, fix this.
- It took so long to stumble onto why this is happening.
- I was using this lib to save time, and pain.... :/
Using these versions:
"dotenv": "14.1.0",
"dotenv-expand": "^9.0.0", <--- And tried v10 (latest), same outcome.
I second that request.
My use case is that I'd like to use the .env files to hold defaults for my env vars, and they have the same name externally as internally to reduce confusion.
So even if the CI sets a env var named MY_VAR to an empty string, the .env default value defined like MY_VAR=${MY_VAR:-DEFAULT} will be respected.
And in the app I don't have to care the source of value, just rely on MY_VAR
+1 on this request
I stumbled on that issue as I was trying to set a default variable if it ever was not available.
For example, I was willing to set the $GID variable if it was not available:
GID="${GID:-${GROUPS:-$UID}}"Let's admit that my case is a bit overcomplicated and only use the following:
GID="${GID:-$UID}"I would still get the same error, while it is completely missing the point of the syntax, that is a valid one.
I might not expect the substitution to work well in that specific case, but neither would I expect it to crash that badly either.
Thanks for your time maintaining this awesome package 😄
No updates about this issue?
same issue here
same issue too.
looking into this soon. thank you for your patience everyone. know it is frustrating. lots to keep up on!