Circular dependencies don't always work

[gentoo90]

I stepped on this while trying to add some webassembly to a Visual Studio Code extension.
Right now output.js and output_wasm.js both import each other and this doesn't work in VS Code because import_b is empty when WebAssembly.instantiate is called:

While the same file imported in the main module has everything in place:

Everything started working like a charm after I manually moved stuff required by wasm into a separate file and imported it from both files.

You can see the example extension in https://github.com/gentoo90/vs-wasm
Uncomment line 24 in tasks.json and relaunch to see the error.

[alexcrichton]

Aha thanks for the info! This actually sounds like a great idea to me, I was a little wary as well about the circular imports.

I think we can totally change codegen to emit three files, one JS module for the "real interface", one for the wasm, and one for internal support. That I think should allow us to break cycles as the internal support doesnt import anything and the wasm only imports that

[alexcrichton]

So I've actually found out that this very easy to do and may actually not be possible (oh dear!)

In #48 though I've tweaked the codegen as it looks like webpack was also not happy with our circular imports. I've tweaked it though such that webpack now works, mind giving VSCode a spin to see if it now works as well?

[alexcrichton]

Oh right I meant to expand on why this may be hard.

In general wasm-bindgen stuff falls in two categories, imports and exports. We're generating a JS module where the exports must be present, but the imports can go anywhere. Both the imports and the exports reference the wasm module itself (to do things like read memory, deal with strings, etc). The wasm module also references imports.

Finally, we've got a category of "shims" which is various runtime support in JS for wasm-bindgen, and both exports/imports need this functionality.

Or otherwise, in a pretty graphviz diagram:

So clearly there's a cycle here but it's purely an internal cycle, doesn't have to be user facing. In that sense I don't think it's possible to actually break all cycles but I'm also curious if the construction in #48 helps! I personally know very little about cyclic imports in ES6 modules and how they're supposed to work, but I'm hoping we can squeak by...

[gentoo90]

Ok, so I updated wasm-bindgen and gave it one more try, and it failed again with the same error. But then I thought that maybe import order matters. Aaaand it does. After I put import { booted } before import ffi from 'wasm.js' it started working properly. But I'm not sure if that trick is reliable cause it may depend on JS engine.

[alexcrichton]

Interesting! I'm unfortunately pretty unfamiliar with how circular imports are supposed to work but it's good to know that it at least works somewhat!

[alexcrichton]

I'm going to close this for now as I think it's very non-trivial to get away from this, but it seems to be working in most packaging systems.