Wasm-bindgen newbie question on ergonomics of re-exports

One annoying ergonomic issue I’m encountering when trying to make a wasm crate with wasm-bindgen for my rust crates is how to generate bindings for types that come from other crates. I end up creating a lot of wrapper types like the following pseudocode:

extern crate my_rust_crate;
extern crate wasm_bindgen;

use my_rust_crate::Foo;

#[wasm_bindgen]
pub struct WrapperFoo(Foo);

#[wasm_bindgen]
impl WrapperFoo {
    pub fn bar(&self) -> () {
        self.0.bar()
    }
}

While sometimes this would be necessary anyway (e.g., to explicitly parameterize generics or to provide wrapper function impls for trait methods that can’t use wasm_bindgen anyway), most of the time it’s just noise and boilerplate. I thought about moving the wasm bindings into the base rust crates themselves to get around this, but that’s not practical because the crates would need to be cdylibs instead of normal rust dylibs, which isn’t something that can be set based on feature flags.

How are others dealing with these sorts of issues? Can this be avoided if both the base rust crate and wasm crate are in a cargo workspace? There aren’t yet established best-practice wasm crates that I know of to read for inspiration.

1 Like