[Beta] Dotenv expand is failing the build - consider reverting processing process. env

Describe the bug

Hi, One of the breaking changes in vite late alpha is preventing us to run the beta: https://github.com/vitejs/vite/commit/d5fe92cd2a0be2b8636e876a81a63921a808afb2

Parsing / expanding with dotenv process.env variable is highly disruptive and certainly can lead to unexpected behaviour. Here we are testing Warp terminal, it is injecting this WARP_PS1 containing $. I can see how this could randomly bite other users and some side effects might be hard to debug (if it actually expand some variables from process.env)

Please consider reverting this change, this issue was already reported in the past but now that process.env is parsed we don’t have any control on these vars for escaping the $ so the workaround cannot be applied see https://github.com/vitejs/vite/issues/6858#issuecomment-1036105762

Reproduction

Not relevant

Steps to reproduce

No response

System Info

Not relevant

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it’s a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[patak-dev]

Maybe we can have a patch in the vite monorepo instead of forking until this is implemented upstream?

[bluwy]

I think we still need expand process.env, which is intentional and allows us to use ci’s environment variables in env files, which is very useful

Yeah we should expand .env using process.env, but we shouldn’t expand the process.env itself.

Maybe we could escape process.env before passing to dotenv-expand? That way I think we could avoid forking.

I think that brings perf implications compared to forking it. Maybe looping in @motdotla if this could be implemented upstream? Summary so far is that we want to read process.env when expanding, but we don’t want to write back to process.env (skips this code).