Node + Electron environment is getting more difficult to use

[yosoymin]

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.11 (d3432e7)
clang version 21.0.0git (https:/github.com/llvm/llvm-project 0f0079c29da4b4d5bbd43dced1db9ad6c6d11008)
Target: wasm32-unknown-emscripten
Thread model: posix

Since I've updated from Emscripten version 3.1.68 to 4.011, I can't use a small workaround I found to execute my application inside Electron and run all my system tests, just like any native application, by comparing generated screenshots and other metrics. This was the workaround added to any --pre-js JavaScript file:

// Workaround for https://github.com/emscripten-core/emscripten/pull/22619
ENVIRONMENT_IS_NODE = typeof process == 'object' && typeof process.versions == 'object' && typeof process.versions.node == 'string';// && process.type != 'renderer';

Since pull request 22619, using Electron and NodeFS together has become more complicated. In the latest version of Emscripten (4.0.11) the workaround requires modifying the internal file emsdk/upstream/emscripten/src/parseTools.mjs with this change:

function nodeDetectionCode() {
  //return "typeof process == 'object' && process.versions?.node && process.type != 'renderer'";
  return "typeof process == 'object' && process.versions?.node";  // NEBULA-CHANGE: to be able to exeute in Electron
}

Why is it needed to check the process.type != 'renderer'?

I've found that my previous workaround is not working because the global variable ENVIRONMENT_IS_NODE is rechecked like this:

#if ENVIRONMENT_MAY_BE_NODE
if (ENVIRONMENT_IS_NODE) {
#if ENVIRONMENT.length && ASSERTIONS
  const isNode = {{{ nodeDetectionCode() }}};
  if (!isNode) throw new Error('not compiled for this environment (did you build to HTML and try to run it not on the web, or set ENVIRONMENT to something - like node - and run it someplace else - like on the web?)');
#endif

Is that necessary? ENVIRONMENT_IS_NODE is already assigned to the same expression nodeDetectionCode(), so this is redundant, right?
I'm probably missing something, but this gives me headaches every time I want to update Emscripten.

Does anyone know how to use NodeFS and Electron properly without any workarounds?

[Pokoi]

I've encountered this same issue when using Emscripten and Electron with NodeFS. I had assumed they were incompatible, but the code snippet you provided seems illuminating. Hopefully anyone give us an explanation about that.

[Llermy]

That's some good insight. I wanted to +1 this since I had been facing the same issue when using Electron and Node and I did not go further since seeing how to patch the Emscripten code everytime end up giving me headaches as well. I hope someone knows of a better solution.

[kripken]

I apologize for the complexity here. This is not an environment that we test, so it is hard to make sure we don't change things.

Some ways to improve things here:

• Perhaps we can support electron using Replace ENVIRONMENT_* logic with Web default + polyfills? #12203 , that is, including a "polyfill" JS that makes things work. That would prevent people from needing to patch things locally (they would just --extern-pre-js that file). Would be good if someone familiar with electron can try that.
• If someone can figure out a way to test this in our CI, we could prevent regressions in the future.

[sbc100]

Regarding the check for process.type != 'renderer', that was specifically added in #22619. It seems like the goal is that electron should specifically not be detected as ENVIRONMENT_IS_NODE .. that seems to be the exact opposite of what you want there.

Perhaps @idranme can comment as to why you don't want ENVIRONMENT_IS_NODE inside of your electron app?

[idranme]

Regarding the check for process.type != 'renderer', that was specifically added in #22619. It seems like the goal is that electron should specifically not be detected as ENVIRONMENT_IS_NODE .. that seems to be the exact opposite of what you want there.

Perhaps @idranme can comment as to why you don't want ENVIRONMENT_IS_NODE inside of your electron app?

I did this because of an error message, but I have forgotten what that error message was. In addition, I believe that the renderer process belongs to the browser environment, not the Node environment.

[idranme]

The above code is executed within the renderer process. The error shown in the image affects builds that use -sEXPORT_ES6, because such builds include the statement const { createRequire } = await import('module'). Avoiding detection as ENVIRONMENT_IS_NODE can mitigate this issue

[yosoymin]

Regarding the check for process.type != 'renderer', that was specifically added in #22619. It seems like the goal is that electron should specifically not be detected as ENVIRONMENT_IS_NODE .. that seems to be the exact opposite of what you want there.
Perhaps @idranme can comment as to why you don't want ENVIRONMENT_IS_NODE inside of your electron app?

I did this because of an error message, but I have forgotten what that error message was. In addition, I believe that the renderer process belongs to the browser environment, not the Node environment.

In my case, I'm using Electron with nodeIntegration and nodeIntegrationInWorker, allowing me to utilize Node APIs and NODEFS in the web logic to access the native file system. For example, without that, the next statement will fail:

FS.mount(FS.filesystems.NODEFS, { root: origRepoDir }, repoDir);

because there is an assert(ENVIRONMENT_IS_NODE); inside the mount method.

Perhaps, when using the Electron nodeIntegration feature, the assumption process.type != 'renderer' is not met.

[sbc100]

It sounds like we probably need to add more tests for running in the electron environment. Would one of be able to look into adding more tests.

I'm a little worried that we will end up with get more settings / options / environments at the end of this, but perhaps its unavoidable :(

[xushengfeng]

Maybe emscripten can output glue scripts without environment detection and wasm module loading, passed into wasmBinary by ourselves

[sbc100]

Maybe emscripten can output glue scripts without environment detection and wasm module loading, passed into wasmBinary by ourselves

I believe this is what -sMINIMAL_RUNTIME does by default.. but in that mode I don't think you can use the NODERAWFS stuff.

In the normal non-minimal-runtime I believe you can set Module['wasmBinary'] before loading the program if you want to do that.

Making a version of emscripten that doesn't try to detect the platform at all sounds like a fair amount of work. A lot of code in emscripten depends on these platform globals (i..e ENVIRONMENT_IS_XXX)

[kripken]

Making a version of emscripten that doesn't try to detect the platform at all sounds like a fair amount of work. A lot of code in emscripten depends on these platform globals (i..e ENVIRONMENT_IS_XXX)

I think #12203 may be a practical a way to get there: the end goal is to use just the Web, and support other things by modular polyfill scripts on top. That might be a lot of work, but perhaps we can move there gradually, reducing the number of environments, and supporting similar ones with polyfills. E.g., for Node+Electron, we would support it as ENVIRONMENT_IS_NODE + a polyfill?