Should getenv() map to process.env in node.js?

[zeux]

Apologies if this has already been discussed in a different issue, I wasn't able to find one.

In node.js, Emscripten more or less behaves as a native program:

• You get access to native file system when NODERAWFS is specified
• You get access to spawning processes via system()
• However, getenv() is virtualized instead of using process.env

This can be worked around using EM_JS et al of course, but is there a reason why getenv() doesn't just magically work on node by looking for the key in process.env?

[juj]

I believe there is no reason to keep getenv/setenv virtualized - nobody just has cared about implementing that behavior.

Although for filesystem we do default to providing a virtualized one, so perhaps we will still want to default to virtualized environment, unless one opts in to making a non-containerized build.

[kripken]

Yes, we've defaulted to a virtualized environment, so that the JS output works the same on the Web, Node.js, and elsewhere. I think we should keep that property - it's a good guarantee to have. But we should make it easy to get direct OS access too.

Maybe we could generalize NODERAWFS to a RAW_OS flag that gives raw/direct access to the underlying OS? It would enable NODERAWFS when on Node.js, and also direct process.env support there.

I'm unsure whether such a flag would be useful outside of Node.js, since there is no "raw OS" support possible on the Web. If it's just for Node.js, maybe we could just make NODERAWFS also enable process.env, maybe just renaming it NODERAWOS?

[kripken]

Oh, to answer my own question, there is also wasm2c mode which also needs this. So a single RAW_OS that enables raw OS access on Node and on wasm2c makes sense I think.

I think we can rename NODERAWFS to that, but there is a small risk of breakage on code using that for files but that would be surprised to get env vars too.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.