Emscripten: Make JS output Node or web only

[surma]

Currently, the JS glue code output by Emscripten targets both Node and Web and does some detection what environment it is running in.

This is problematic for 2 reasons:

1. It makes web users download code they will never run or use
2. It breaks bundlers as they are trying to resolve require() directives that can’t be resolved.

I think a good solution would be to allow users to specify which environment they are targeting and only emit the code for that specific target.

[brodybits]

What about a more modern solution such as Universal JavaScript as described in [1] and [2]?

[1] https://hackernoon.com/how-to-make-universal-javascript-applications-part-1-90e9032bc471
[2] https://cdb.reacttraining.com/universal-javascript-4761051b7ae9

[surma]

The more universal, the better!

The problem here is that the node path needs the fs module to load the wasm file from disk while the web path uses fetch(). AFAIK, there is no universal code for this.

[brodybits]

Why not make a universal module for this one?

If we really need separate code for disk vs web I would favor generating separate code for this part only.

[curiousdannii]

See also #5794 and #5836.

You should be able to clean up a lot of this code through using a minifier, for example see https://github.com/mishoo/UglifyJS2#conditional-compilation-api

In general though, it would probably be better for this to both be controllable through a compiler time setting. A PR would be welcome.

@brodybits I'm not really sure why you bring up universal JS as something new, as that's what this is already doing: abstracting over browser differences so that one library can be run anywhere.

[kripken]

I found an old issue about this: https://github.com/kripken/emscripten/issues/1140 the conclusion there was somewhat negative, but I do think this is worth doing even if it is only for a few K of savings. PR would be very welcome.

[kripken]

Re-reading this, I apologize for overlooking point 2, that it breaks bundlers. We should fix that at high priority, I'm working on a PR now.

[curiousdannii]

It doesn't necessarily break bundlers, you may just have to change some settings. For Browserify that means using --bare.

[surma]

True, it doesn’t _break_ bundlers, but it needs some re-configuration that is easily avoided imo (see this webpack issue). It also adds a dependency to the module during static analysis that is not actually a _real_ dependency.

In general it seems more idiomatic (danger, personal opinion) to only emit code for one platform if it can’t be written in a universal way and let the developer choose which platform to target. For backwards-compatibility’s sake the current behavior could stay the default and a new flag could be added to explicitly opt into emitting code for only one platform.

[kripken]

I see, thanks @curiousdannii. Perhaps less urgent than I thought, then. Still, it seems nice to have this.

Simple implementation up at #6565, comments very welcome there.

[kripken]

Implemented by that PR.