-
-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Env var expansion breaking change in versions 11.0.3 - 11.0.6 affecting Vite #124
Comments
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. To proceed I just need a proposal on expected behaviour to resolve the collision of cases. |
Hey @motdotla, how should we proceed? |
I'm having the same issue. @nazed thank for taking care of this! |
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:
Expected behaviour, as of dotenv-expand@<=11.0.2 and Vite@<=5.1.1:
Actual result for dotenv-expand@>=11.0.3 Vite@>=5.1.2:
the
-cd-ef-gh
parts is missing nowPossibly 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:
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
Although, I can't agree with such a behaviour because:
The text was updated successfully, but these errors were encountered: