Usage produces fatal error when .env file defines a variable with same name as expanded variable.

[atljoseph]

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.

[alfetopito]

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

[atljoseph]

This seems to be a breaking change with a newer version 2020, too. I guess this part was never tested explicitly before.Sent from my iPhoneOn Apr 18, 2023, at 9:22 AM, Leandro Boscariol ***@***.***> wrote: 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 —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[andrewmclagan]

+1 on this request

[JumpIfBelow]

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 😄

[celorodovalho]

No updates about this issue?

[cyango]

same issue here

[JackZhengSit]

same issue too.

[motdotla]

looking into this soon. thank you for your patience everyone. know it is frustrating. lots to keep up on!

[motdotla]

this is fixed in v11.0.0 (releasing shortly)

here is test demonstrating it is fixed: #111

any recursive call like this will now end up just returning the raw value it was set to.