Environment variables aren't refreshed when the env file is referred to from test/env in the config file

[seaders]

Describe the bug

Very simple .env

VITE_USE_FIREBASE_EMULATORS=true

Fairly simple vite.config.ts

/// <reference types="vitest/config" />

import react from "@vitejs/plugin-react-swc"
import { config } from "dotenv"
import tailwindcss from "tailwindcss"
import { defineConfig } from "vite"
import tsconfigPaths from "vite-tsconfig-paths"

export default defineConfig({
  plugins: [react(), tsconfigPaths()],
  css: {
    postcss: {
      plugins: [tailwindcss()]
    }
  },
  test: {
    env: {
      ...config({ path: "./.env" }).parsed
    }
  }
})

and fairly simple check, either console.log(import.meta.env.VITE_USE_FIREBASE_EMULATORS) or refer to it in App.tsx,

<h1>
        Use emulators -- {import.meta.env.VITE_USE_FIREBASE_EMULATORS} --
</h1>

On start of server, all's as it should. If I go and remove that env, or change it to say, false, what gets printed and shown? That's right true. If I go and completely remove that test area from vite config file, what gets printed? true

To fix this, I have to have the test area not refer to my env file at all. Not at startup, not after, at runtime. There's some weird issue where, once that file's "touched", by that area of test env, it's not reprocessed at all.

And, just to be clear, the server does detect the changes,

10:40:33 PM [vite] .env.development.local changed, restarting server...
10:40:33 PM [vite] server restarted.

They just don't bubble up to the code.

Reproduction

https://stackblitz.com/edit/vitejs-vite-pdplp6t1?file=.env,vite.config.mts

Steps to reproduce

Detailed above, refer to your env file in the test.env section of your vite config file.

System Info

System:
    OS: macOS 15.2
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 547.85 MB / 16.00 GB
    Shell: 5.2.37 - /usr/local/bin/bash
  Binaries:
    Node: 20.11.1 - ~/.nvm/versions/node/v20.11.1/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v20.11.1/bin/yarn
    npm: 10.9.2 - ~/.nvm/versions/node/v20.11.1/bin/npm
    pnpm: 9.15.0 - ~/.nvm/versions/node/v20.11.1/bin/pnpm
  npmPackages:
    @vitejs/plugin-react: ^4.3.4 => 4.3.4 
    @vitejs/plugin-react-swc: ^3.7.2 => 3.7.2 
    vite: ^6.0.3 => 6.0.3

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.

[hi-ogawa]

This is due to dotenv config mutating process.env, which is then passed to import.meta.env by Vite, so test.env in particular is not relevant. Once process.env is muated, probably something related to this issue #17689 is happening.

For your example, you don't need dotenv since Vite supports it out-of-the-box https://vite.dev/guide/env-and-mode.html#env-files If you have a reason to use dotenv and Vitest's test.env option, can you clarify your use case?

[seaders]

My use case is specifically around tests for different environments @hi-ogawa. We've 3 different environments, so the default dev/prod of vite doesn't fit well with our project, and we also run against firebase stuff, which relies on keys that you need for doing things locally (like GOOGLE_APPLICATION_CREDENTIALS), but you can't set them to be in the regular .env file.

In our setup, we normally have things at least like .env.development and something like .sandbox.env, though much of that is legacy stuff that's just been brought along. When a check has needed to be run against a different environment to dev, the easiest thing was to have them defined in env.test and swap to the one you want.

[hi-ogawa]

Btw, you probably need config({ path: './.env', processEnv: {} }) to avoid mutating process.env. https://stackblitz.com/edit/vitejs-vite-kq3j3mkd?file=vite.config.mts

Also for this purpose, there is loadEnv provided by Vite too https://vite.dev/guide/api-javascript.html#loadenv (ah, maybe this one doesn't allow loading a name like .sandbox.env)

[seaders]

I can confirm adding processEnv: {} resolves my issue, and reading up the other issue, it seems like the exact same is/was happening here, env was being mutated and then not refreshed.

On the loadEnv, yeah, we sometimes have to mix and match stuff and really just want to run the tests in the environment we want to run - specifically in vscode with the Vitest extension. It's one thing having things set in stone for the project, but when trying to actively figure out why something's not right with project x in staging, or trying to figure out how badly does feature y work break when against prod (or something stupider than that), I've constantly found that vite's defaults don't give enough flexibility in that regard.

[hi-ogawa]

It looks like config({ path: './.env' }) also doesn't refresh once it's loaded to process.env on first call.
I'll close this for now. If you have a specific usage question, please open a discussion.

[seaders]

Yeah, that's only for tests and I can't think of any use case where that's needed for them.

This issue was all about a test setting was changing/changed a behaviour in the non-test environment, all the while the server saying that it detected the change, reloaded the server, and the page, but didn't reflect the change. I get the underlying issues of the mutated env bug, but there nearly shouldn't be any situation where a test configuration should change the behaviour of the vite server.