[shulaoda]

What

loadDeployEnv now parses .env and .env.production through the shared parseDotenvFile (with expansion disabled) and mergeAndExpand, the same path env validation uses, instead of a hand rolled line parser that shipped raw values. It is now exported so the behavior can be tested directly.

Why

void deploy validates env by expanding ${VAR} and $VAR references across the env files, but loadDeployEnv, which builds the values actually shipped to the worker, used a separate hand rolled parser that only split on the first = and stripped quotes. It never expanded references. A .env with API_HOST=api.example.com and API_URL=https://${API_HOST}/v1 therefore passed validation against the expanded URL while the worker received the literal https://${API_HOST}/v1. Validation stayed green and the deployed value was silently broken, which is exactly the kind of divergence that is hard to notice until runtime.

Safety

The shared path keeps the same file list and precedence, .env first and .env.production overriding it, and runs the same stripInternalEnvKeys step afterward, so plain values, quoted values, and override order behave as before. The only behavior that changes is that ${VAR} and $VAR references now resolve, which is what validation already assumed.

Verification

A new regression test at packages/void/test/unit/deploy-env-expand.test.ts drives loadDeployEnv against a temp project and asserts that a ${VAR} reference resolves both within one file and across .env and .env.production. It fails when expansion is removed and passes with the fix. The deploy-project, deploy-drift, deploy-events, and dotenv suites stay green (79 tests total), and the void package typechecks with tsgo and passes oxlint.