Do not generate bindings for dependencies

[zrzka]

I have two crates - reconfix and cdsl. The former one depends on the later one:

reconfix
  |- cdsl

cdsl crate can be used as a Rust crate and it also contains bindings gated via cfg(target_arch = "wasm32"). NPM package with proper bindings can be generated.

Now I have a reconfix crate, which does use cdsl as a dependency. But when I generate bindings for the reconfix crate, all bindings (JS functions) from the cdsl crate are in the reconfix bindings as well.

Example:

• cdsl contains JS function generate_ui
• reconfix has cdsl as a dependency
• reconfix does not contain JS function generate_ui
• create NPM package / generate bindings and reconfix does contain generate_ui function, which is something I do not want, it behaves like implicit pub use ... reexports

Is there a way how to disable this behavior? For now, I introduced disable-wasm-bindings feature in the cdsl crate. But it's nothing I like or I consider as a good solution. What's the recommended way? Should I split cdsl in two crates, like cdsl (without wasm bindings) and cdsl-wasm crate, which will act as a bridge between Rust & JS only?

[alexcrichton]

Thanks for the report!

This is somewhat nontrivial to do right now, as the transitive behavior of wasm-bindgen is actually intentional. I suspect, though, that like with normal Rust libraries compiled for C it's "best practice" to avoid #[wasm_bindgen] in dependencies like it's best practice to avoid #[no_mangle] unless it's for technical reasons.

We could explore an option like this perhaps, but the information isn't currently available to the CLI tool. Additionally it's not clear I think if we want this long-term because it may end up breaking intermediate dependencies accidentally in some cases.

[zrzka]

Thanks for the reply. We have something like you described, but in the opposite way - enabled by default, feature can disable it. The reason is wasm-pack & this issue. Once 0.6.1 is released, we will modify it, so, by default #[wasm_bindgen] will be disabled and one will have to enable it with a feature (disable-wasm-bindings will become enable-wasm-bindings).

[alexcrichton]

Ah ok makes sense! In that case I think it's probably best to fix it via that, but otherwise this seems reasonable to have as a feature request at least (even if it's not the default behavior) so let's leave it open

[Menschenkindlein]

Hi, I have a related question. Is it possible to explicitly make bindings for something in a dependency crate from the dependent crate? It would be something like

#[wasm_bindgen]
pub use dep_crate::SomeStruct;

This way, the dependency doesn't need to know anything about wasm-bindgen, and the dependent crate is working like a facade.
Now it's possible only by creating a wrapper struct with all required methods by hand. And it won't work for enums at all.
Generally speaking, it would be a much better experience to have exports only in the main crate and only in the main module, as the splicing of exports is quite confusing.
Is it theoretically possible to have something like this?

[alexcrichton]

Unfortunately, no. The macro runs over the AST, so it can't resolve that and figure out how to generate bindings, it needs the source code itself.

[Menschenkindlein]

I see, thanks for the clarification.

[daxpedda]

CARGO_CRATE_NAME and CARGO_PRIMARY_PACKAGE could be used to do this.

The question really is how to design an interface to control this. E.g. a CLI flag or something that allows more fine-grained control.

See also rust-lang/rust#98449.