The nodeJS part of wasm_exec.js is just a simple wrapper to call the wasm binary. Even the usage is usage: go_js_wasm_exec [wasm binary] [arguments]. I wonder whether it will be helpful to add complex flag parsing logic into it.

/cc @neelance

I don't understand this issue. Why are you passing --no-sandbox to wasm_exec.js? Is it that you're using require with wasm_exec.js?

I want to use wasm in electron which integrates the node.js environment. it's catch error when loading *.wasm file. I'm using wasm_exec.js to start wasm, but the process.arg[2] would be a flag named "--no-sandbox", not a file name. so，the follow code catch error:
WebAssembly.instantiate(fs.readFileSync(process.argv[2]) ...

You still haven't told me how exactly you're loading wasm_exec.js.

loading wasm_exec.js in index.html like this:

`

and in index.js:

const go = new Go();
let mod, inst;

WebAssembly.instantiateStreaming(
fetch("main.wasm"), go.importObject
).then(
(result) => {
mod = result.module;
inst = result.instance;
console.log("init done");
run();
}
).catch((err) => {
console.error(err);
})

async function run() {
await go.run(inst);
inst = await WebAssembly.instantiate(mod, go.importObject);
}

Okay, looks like this use case is not yet covered by wasm_exec.js. Could you please try if changing isNodeJS to isNodeJS && require.main === module at

the error does not catch using the new wasm_exec.js. But new problems arise.:
index.js:14 LinkError: WebAssembly Instantiation: Import #5 module="go" function="runtime.scheduleCallback" error: function import requires a callable

WebAssembly.instantiateStreaming.then.catch | @ | index.js:14

Do I need a new version compiler?

by the way, using old wasm_exec.js and changing isNodeJS && require.main === module， still catch error.

By "new", if you mean the wasm_exec.js found in the master branch, then you need to use the Go binary compiled using the master branch. Could you try that ?

You can download and build the Go master branch using gotip.

thanks, I would try it out.

The master tree don't catch the error without changing isNodeJS to isNodeJS && require.main === module! The error may be only in version 1.11.4.

Did you mean "with changing ..." ?

I mean without changing.I compare the master tree with 1.11.4(wasm_exec.js), there are some differents between them. And the master tree did not catche error any more.

Ah I see. So the master branch does not catch the error by default. Interesting. @neelance - thoughts ?

With 1.11 it was

const isNodeJS = typeof process !== "undefined";

now it is

const isNodeJS = global.process && global.process.title === "node";

That's probably enough for your case to have isNodeJS set to false. However, this would also mean that the os package won't work.

os package really doesn't work.
global.process.title === "".
It means I have to import it manually？
electron contains the node environment. Node would be often used.

Yes, in your case the check global.process.title === "node" isn't appropriate. We can try to change it to something that works in your case while still trying to not regress on #28364.

@gtd138 Could you please give this branch a try? https://github.com/neelance/go/blob/wasm-exec/misc/wasm/wasm_exec.js
I tried to make it adapt to different environments.
@SamWhited Could you do us a favor and try it with your Parcel use case as well?

@SamWhited Could you do us a favor and try it with your Parcel use case as well?

I changed how the bundling works and don't have the same problem anymore; it's been a while, so I'm afraid I don't remember what the other problem was or how to reproduce it. Sorry.

@neelance
os pack works, but it catches error again:

Uncaught Error: ENOENT: no such file or directory, open '--no-sandbox'
    at Object.openSync (fs.js:436)
    at Object.module.(anonymous function) [as openSync] (ELECTRON_ASAR.js:160:31)
    at Object.readFileSync (fs.js:341)
    at Object.fs.readFileSync (ELECTRON_ASAR.js:580)
    at wasm_exec.js:474
    at wasm_exec.js:487

So this means that global.require.main === module is true in your case, even if you include it via <script src="wasm_exec.js"></script>? Could you please double check? If yes, then we need to find a different way to detect that the script is not called as a standalone executable.

Yes, global.require.main === module is true, and I still include it via <script src="wasm_exec.js"></script>.

This is unexpected, but it is JavaScript after all... So maybe we should keep the global.process.title === "node"? Do you see a better way to detect Electron?

I found it from Electron's official website. It is process.versions['electron'] != "undefined" or process.versions.hasOwnProperty('electron') == true, if current env is electron.

@neelance

Would this issue be fixed?

@neelance @agnivade

I have updated the branch https://github.com/neelance/go/blob/wasm-exec/misc/wasm/wasm_exec.js. Does this work for you?

It works! The os package works, too. Thanks.

Great. I'll create a CL in the next cycle.

Ok. Does it mean it will be supported in 1.12?

No, the next cycle is 1.13. 1.12 is feature frozen.

Ah,I see.

Change https://golang.org/cl/164665 mentions this issue: misc/wasm: better adapt to different JavaScript environments