dotenv-expand
dotenv-expand copied to clipboard
motdotla
Env var expansion breaking change in versions 11.0.3 - 11.0.6 affecting Vite
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
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.
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.
