Add new 'none' ENVIRONMENT

[curiousdannii]

So in my project I'm manually downloading the WASM file, mainly so that I can do it in parallel with other large files, but also potentially so that I could add a download progress meter.

What would you think about adding a new ENVIRONMENT option of 'none' which would stop all shell type code from being emitted, would prevent the JS from trying to locate and download the WASM, would make the resulting code perfectly platform-agnostic, with no require calls, etc?

Things that would be slightly less optimal under this situation:

• _emscripten_get_now might be less accurate in Node
• something would need to be done for the TTY get_char in Node
• crypto in Node. Would it just have to abort? Fall back to Math.random? (I assume there are good reasons not to, as it currently aborts rather than falling back to Math.random.)

[kripken]

For your use case is standalone wasm the best option? That emits no JS at all, just wasm, that you download yourself.

If not, then I think we could make -s ENVIRONMENT='' (empty list of environments) work, yeah, using just 100% generic JS, no node or web details, etc. That code would have no way to download the wasm, so it would depend on a hook from the user to get the wasm binary (or compiled WebAssembly.Module) I suppose?

[curiousdannii]

No, I need the JS because I use FS, EM_JS, Asyncify, etc.

I thought adding 'none' would be clearer. The default is already currently ''.

[kripken]

Ah yes, the empty string means "everything" right now, so we do need something like none.

[curiousdannii]

With the new potential way of doing environment stuff, I'm wondering if a setting like MANUALLY_PROVIDE_WASM might be better instead - it would just cut out all of the loading code in expectation that wasmBinary would be provided on Module.

[kripken]

@curiousdannii I think that makes sense, since the core of your idea is around loading the wasm.

We already have a Module.instantiateWasm hook, does that do what you want? (see src/preamble.js)

[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.

[curiousdannii]

This is still worth considering

[curiousdannii]

I've found that this is actually pretty necessary.

So currently I'm using ENVIRONMENT=web because I don't want any of the require() calls to be included, so that it will work with EXPORT_ES6. I can still run it in Node though as long as I manually load and set Module.wasmBinary. But if I then enable ASSERTSIONS, it complains that it's not running in the web. But what I actually want is just no web or node code to be included!

Edit: And setting ENVIRONMENT=node still doesn't work in ES6 modules in Node because require isn't present!

[sbc100]

Would making ENVIRONMENT=node + -sEXPORT_ES6 work (by removing require statements) be enough to address your concerns?

Maybe we could have something like ENVIRONMENT=js_module .. would that make sense?

[curiousdannii]

ENVIRONMENT=node + -sEXPORT_ES6

This still outputs require, __dirname etc.

I've previously been using ENVIRONMENT=web because it's the most platform agnostic option, however if you then turn on ASSERTIONS it has runtime errors if it can't find the browser. So the assertions are testing for things that it doesn't actually use. 😕

[sbc100]

ENVIRONMENT=node + -sEXPORT_ES6

This still outputs require, __dirname etc.

Yes, but presumably it should not, since the user is asking for an ES6 module.. in which case require should not be in the output.

If we fixed that .. would that work for you?

[curiousdannii]

That would be a much bigger improvement, though we've been waiting a long time for that haha.

A none option would still be nice for reducing file size a little though.

[sbc100]

Should EXPORT_ES6 imply none? By that I mean, can an ES6 module access any node or browser-specific APIs ever?