Env var expansion breaking change in versions 11.0.3 - 11.0.6 affecting Vite

[nezed]

Hello dear maintainers,

we were using env expansion references without braces for a kebab-cased values, which are now broken.

This breaking change were brought with [email protected] patch published recently, as the dotenv-expand dependency got updated ^10.0.0 to ^11.0.3.

The breaking change seems to be made intentionally to allow default values in substitutions without braces, which stops me from opening a PR.

In any case, it brakes any content in kebab case, as everything after the substitution is dropped.

Reproduction

Here's the lightweight reproduction you can try:
https://stackblitz.com/edit/stackblitz-starters-p3yqwk?file=.env

Given following .env file as example:

# .env
SOURCE=12345
EXPANDED=ab-$SOURCE-cd-ef-gh

Expected behaviour, as of dotenv-expand@<=11.0.2 and Vite@<=5.1.1:

console.log(import.meta.env.EXPANDED) // ab-12345-cd-ef-gh

Actual result for dotenv-expand@>=11.0.3 Vite@>=5.1.2:

console.log(import.meta.env.EXPANDED) //ab-12345

the -cd-ef-gh parts is missing now

Possibly related issues

I was able to find issues #117 (fixed with 11.0.4), #120 (fixed in (11.0.5) and #123.
Meanwhile, none of them mentioned the case with trailing content after the env variable reference.

Affected versions

All mentions versions is affected:

• 11.0.3
• 11.0.4
• 11.0.5
• 11.0.6

This particular case was working fine for 11.0.0 - 11.0.3 and for ^10.0.0

Syntax collision with 'default values'

This breaking change seems to be an intentional feature, as I can see via tests

• https://github.com/motdotla/dotenv-expand/blob/v11.0.6/tests/main.js#L400-L408
• https://github.com/motdotla/dotenv-expand/blob/v11.0.6/tests/.env.test#L42-L43

Although, I can't agree with such a behaviour because:

• That breaking change could be easily avoided
• It doesn't seems to be a standard syntax, example with bash:

  sh-5.2$ echo "$SHELL-extra"
  /bin/bash-extra
  

• For me it sounds that default variables have to be always go within braces, to make it bullet-proof for both, the users and the implementation, as the implementation should be easy to avoid ReDoS

[motdotla]

i'll look into this and we might go back on that new default. or might provide a different solution. thank you for raising this.

[nezed]

Hey @motdotla, thanks for looking into this.
I'd be happy to prepare a PR since I already reverse-engineered the regex laying in the heart of dotenv-expand.

To proceed I just need a proposal on expected behaviour to resolve the collision of cases.

[nezed]

Hey @motdotla, how should we proceed?

[bitbirddev]

I'm having the same issue. @nazed thank for taking care of this!