In worker threads, process.env is case-sensitive on windows

[leumasme]

Version

v18.17.0

Platform

Microsoft Windows NT 10.0.19042.0 x64

Subsystem

worker_threads / process

What steps will reproduce the bug?

• Set the environment variable "fookey" to "barvalue" (or any other variable name/value)
• Create the following files in a fresh directory:

// main.js
const { Worker } = require("worker_threads");
const path = require("path");

const worker = new Worker(path.join(__dirname, "worker.js"));

console.log("in parent:")
console.log("barkey:",process.env.barkey)
console.log("BARKEY:",process.env.BARKEY)

worker.on("message", (data) => {
    console.log("in worker:")
    console.log("barkey:", data.barkey);
    console.log("BARKEY:", data.BARKEY);
});

// worker.js
const { parentPort } = require('worker_threads');

parentPort.postMessage({
  barkey: process.env.barkey,
  BARKEY: process.env.BARKEY,
});

• Run main.js using node: node main.js

How often does it reproduce? Is there a required condition?

Always reproduces (on windows)

What is the expected behavior? Why is that the expected behavior?

On windows, environmentvariables are case-insensitive.
Thus, we would expect to see the values of "barkey" and "BARKEY" to be equal within both the main context and the worker context.

in parent:
barkey: foovalue
BARKEY: foovalue
in worker:
barkey: foovalue
BARKEY: foovalue

What do you see instead?

In the main context, the values are equal, but in the worker context, only fookey (which has the same casing as the env var we set) returns a value

in parent:
barkey: foovalue
BARKEY: foovalue
in worker:
barkey: foovalue
BARKEY: undefined

Additional information

process.env is meant to be case-insensitive as documented in the process docs here:

On Windows operating systems, environment variables are case-insensitive.

import { env } from 'node:process';

env.TEST = 1;
console.log(env.test);
// => 1

The worker_theads docs don't mention an exception to this process.env behavior, so one would assume it applies there too.

Related issue that lead to the discovery of this behavior: httptoolkit/httptoolkit-server#91

[daeyeon]

Reopening for another opinion on #49008