GeezerVison

I understand the concern. Any mimicking could always break where we least expect it. And I think this issue also come from such a mimicking based on copied environment variables.

In this case, do you think it would be better to document the limitation of the copy? Alternatively, if you have any other suggestions, I would be glad to hear them.

CI: https://ci.nodejs.org/job/node-test-pull-request/53055/

do you think it would be better to document the limitation of the copy?

You may want to get opinions from more people but that would be my suggestion, yes.

I'm actually leaning towards that way too now. Will open another PR.

Closing in favor of #49008

I'm sorta -.5 on this pull request. Yes, real environment variables are case-insensitive on Windows but deliberately mimicking that behavior for fake environment variables feels kind of yuck.

I expect it'll end up confusing people coding on Windows but deploying on Linux.

@bnoordhuis @daeyeon As a counterpoint: this current behaviour causes problems that are very confusing when coding on Linux but deploying on Windows (and I have hit issues related to this specifically in production).

Similarly, it will cause confusion when just coding on Windows normally, regardless of deployments, when correct & worker-compatible code inexplicably works differently just because it was moved from the main thread into a worker.

Is it possible to reconsider closing this?

A motivating example:

• Launch a Node process, with both HTTP_PROXY and http_proxy env vars set to the same value (useful for Linux, where these are different values, and in quite a few weird cases apps will prefer one or the other).
• On Linux, reading HTTP_PROXY or http_proxy in the Node process will always work, as expected - great.
• On Windows, due to case insensitivity, those collapse into a single environment variable.
• On Windows in the main thread, reading both variables works just the same as on Linux - great.
• On Windows within a worker thread, only the http_proxy lowercase env var is now set and the uppercase env var has mysteriously disappeared, due to this issue. Even though the application was launched with HTTP_PROXY set explicitly, that value is gone in the worker thread - very bad.

Effectively unsetting environment variables unexpectedly could cause all sorts of serious problems, and is definitely confusing, even if it's documented. I wouldn't be surprised if the inconsistency more generally caused other weird edge cases.

It would be much better to fix this so env vars on Windows always work the same everywhere, rather than just documenting the behaviour as broken in workers.

@leumasme @pimterry Apologies, I assumed there were no objections to addressing issue by the documentation. I should have pinged before closing it. Reopened the issue instead of this PR.