Ingvar Stepanyan

Oh, of course, I just think it's useful for visibility if someone is looking through bugs by filtering labels :) (maybe it's just my weird habit though)

Probably part of the same issue: this seems to apply to exports as well. E.g.: ```rust #[wasm_bindgen(js_name = MyStruct2)] pub struct MyStruct; #[wasm_bindgen] impl MyStruct { pub fn do_smth(&self) {}...

Oh... looks like for exports that workaround doesn't work: ```rust #[wasm_bindgen(js_name = MyStruct2)] pub struct MyStruct; #[wasm_bindgen(js_name = MyStruct2)] impl MyStruct { pub fn do_smth(&self) {} } ``` still generates...

For now I worked around this by renaming struct in the Rust source and using `#[allow(non_camel_case_types)]` but yeah seems like a bug.

> While for examples Rust passes a clear path like `-o D:\.cargo\target\wasm32-unknown-unknown\debug\examples\demo-9a0b809269285348.wasm` and sets `CARGO_BIN_NAME=demo`, for integration tests Rust passes `-o D:\.cargo\target\wasm32-unknown-unknown\debug\deps\foo-fa13eb71b0a929d8.wasm` where the only distinguishing characteristic is the hash...

> The only issue I'm concerned about is that we need to distinguish the main library vs examples and tests, as we don't want to produce the main JS+Wasm output...

> We should probably follow [rust-lang/cargo#6790](https://github.com/rust-lang/cargo/issues/6790) and see if this works for us or otherwise provide feedback. Oh yeah that's a nice one. Sgtm, so first step is definitely just...

Extra context: although initially I thought of this separately, I recently found out this is exactly what wasip2 is doing via https://github.com/bytecodealliance/wasm-component-ld, so it's not such a crazy idea after...

Unfortunately, it's a known long-standing issue in Serde itself. https://github.com/serde-rs/serde/issues/1183 Nothing we can do on specific deserializer side.

You are right, sorry, I overlooked that. Can you provide a minimal repro that works in isolation? Eg in your code snippet it's unclear where data field comes from, ideally...