Synchronous access to module compiled with WASM=0

[nrabinowitz]

I'm using emscripten to compile C code for the h3-js library. The library is currently compiled as JS, not WASM (though we'd like to also add a WASM version as well in the future). We're currently using emscripten v1.38.43, and I was planning to upgrade, but after some digging I can see that there's a breaking change in v1.39.16 to return a Promise instead of the module itself when using MODULARIZE.

I can't use the async approach without forcing all of my library consumers to import h3-js in an async manner as well, which is a breaking change and contrary to the goals of the library and expectations of the users, which assume that the library is just a set of pure functions.

My assumption is that if I'm not using WASM, the initialization of the module is actually synchronous. Is there a way to synchronously access it in this case? The alternative seems to be to stay on our current version of Emscripten indefinitely.

[sbc100]

It looks like this was done in #10697, perhaps? Maybe @lourd has some advise on how to proceed. Its not just JS that allows for synchronous access, small wasm modules can also be loaded synchronously?

Is it possible that your users could synchronously import h3-js but that those functions that come from emscripten would not be available to them right away?

[kripken]

When WASM_ASYNC_COMPILATION=0 (async compilation is disabled) we do still do everything synchronously during startup, so things almost work. It looks like the only issue is that in MODULARIZE mode we still return a Promise in that case, but I agree that is not consistent. So I think this is a bug in the combination of those two flags, which wasn't noticed. I think we should fix this by making synchronous compilation return the Module object in that case. I opened #12650 for that now.

[nrabinowitz]

Thanks for the quick response! That looks great.

Is it possible that your users could synchronously import h3-js but that those functions that come from emscripten would not be available to them right away?

I did consider this, but "Here's a library, when you call its functions they may fail non-deterministically" didn't seem like the best developer experience 😁 .