Open jcrist1 opened 1 day ago
and include their use in the generated diplomat-wasm.mjs, but don't automatically generate bindgen (i.e. generating {lib}_bg.js) (and document using wasm-bindgen)
Can you expand on this more? What do you mean by "don't automatically generate bindgen", would that mean not doing anything we are doing now?
I'm generally okay with a way to config that "hey there's wasm-bindgen here, do the thing to make wasm-bindgen work" if it's just a matter of configuring an additional import. I don't want to lose functionality we have right now.
I'm not in favor of calling wasm-bindgen, but you aren't proposing that.
Problem
I ran into an issue while using diplomat to create js bindings for a library I'm working on. The library has dependencies which themselves seem to depend on wasm bindgen. The generated wasm expects interfaces provided by wasm_bindgen in the form of
I created a minimal reproducible example here: https://github.com/jcrist1/diplomat-dbg/tree/6649bacd8e004f82814510774acde572625be891/wasm_bindgen
Workaround
I found a relatively easy workaround, but did have to spend a lot of time debugging to figure it out. Just needed to run
wasm-bindgen
on the generated wasm, use that for the module, and add a line toimports
indiplomat-wasm.mjs
:Proposals:
wasm-bindgen
seems pretty embedded in a lot of crates that support wasm, and is a big part of the rust wasm ecosystem, so some kind of support would be nice, but it feels like directly integrating with wasm-bindgen doesn't seem like it aligns with diplomat's goals. I came up withdiplomat.config.mjs
, and include their use in the generateddiplomat-wasm.mjs
, but don't automatically generate bindgen (i.e. generating{lib}_bg.js
) (and document using wasm-bindgen)I hope 1. would not be too much, but I would prefer 2. I don't think 3. makes sense as dipomat doesn't seem to do really do anything to the compile step.