Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mirror entire environment under node #18820

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Mirror entire environment under node #18820

wants to merge 1 commit into from

Conversation

sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Feb 22, 2023

One can still use -sDETERMINISITIC to avoid this behaviour.

Fixes: #18816

One can still use `-sDETERMINISITIC` to avoid this behaviour.

Fixes: #18816
#if ENVIRONMENT_MAY_BE_NODE && !DETERMINISTIC
if (ENVIRONMENT_IS_NODE) {
// Under node we mirror then entire outer environment
env = process.env;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is breaking change, I think.
For example, there could be OS shell variable which would point to files which do not exist on VFS.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible yes. Should we prune the environment? Or perhaps only do this when NODERAWFS is used (i.e. when all paths would be valid)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, given that folks can still override with using the ENV global in JS, do you think it would be a problem in practice?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am also a little worried about breaking changes here.

Comparing this to the filesystem, by default we are sandboxed, and only use minimal things from the environment as makes sense (or no things, in DETERMINISTIC mode). The user can opt into NODEFS or NODERAWFS to get direct/unsandboxed access to the outside. Maybe something similar makes sense for the environment?

If that direction sounds relevant, I'm not sure what's best but options could include a new option, or adding a new "node direct" option (for both this and files), or perhaps bundling with NODE[RAW]FS somehow.

Copy link
Collaborator Author

@sbc100 sbc100 Feb 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about in the default case.. should certain env vars be allowed to pass though by default? e.g. LANG and LC_* were specifically requested in #18816. Is there any reason to not pass those ones through?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think specific ones might be ok on a case by case basis.

@kleisauke
Copy link
Collaborator

Instead of this PR, perhaps it would be useful to document at https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#interacting-with-code-environment-variables that it's quite easy to mirror the entire environment on Node.js with:

Module.preRun = () => {ENV = Object.create(process.env)};

(see #3948 (comment) where this was originally mentioned)

@kleisauke
Copy link
Collaborator

FWIW, the reason I mentioned this is that Rust no longer test the wasm32-unknown-emscripten target triple on CI due to this:
rust-lang/rust#116381
rust-lang/rust#116362 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Do not overwrite LANG on NodeJS
4 participants