Stabilizing `convert` module and exposing `describe` module

[demhadais]

Hello, I use wasm-bindgen extensively, usually to generate javascript classes with the wasm_bindgen macro. For common ecosystem types (like date-time stuff or uuid), I often end up creating newtype wrappers and implementing the traits in wasm_bindgen::convert and wasm_bindgen::describe myself. I'd like to contribute these implementations upstream, but this poses semver compatibility issues for those crates as the convert and describe modules are explicitly documented as internal and unstable.

So the point of this issue is to ask - is there a path towards stabilizing these traits and providing them as the official recommended interface to make Wasm-compatible types? I'd be happy to help with any work that needs to be done before getting to that point.

Thanks!

[demhadais]

Upon further reflection, I realized it would probably make more sense for the implementations of these conversion traits to live in wasm-bindgen, rather than the ecosystem crates I was talking about. It's more logical for the conversion layer (wasm-bindgen) to specify how to convert types, as opposed to the types themselves. This is how pyo3 works, and it sort of follows the convention established by the serde ecosystem.

Would the maintainers accept PRs that implement the traits in wasm_bindgen::convert and wasm_bindgen::describe (behind feature flags of course)? That way, things like this just work:

#[wasm_bindgen]
pub struct MyStruct {
    pub id: uuid::Uuid
}

As a start, I'd be happy to submit PRs that implement support for the following types:

• types from jiff. I'd probably implement support for the legacy Date type as well as for the more modern Temporal API, each behind different feature flags or something
• Uuid from uuid. Specifically, I'd implement the wasm-bindgen conversion traits for specific formats of Uuid (hyphenated, without hyphens, etc), as suggested in uuid-rs/uuid#844
• serde_json::Value and friends

Those are the most immediately useful for me, but it wouldn't be hard to add support for types from other common crates:

• chrono
• time

Anyways, I'd love to hear thoughts. Thanks!

[daxpedda]

We can't stabilize the convert or describe module because we would then be unable to break the encoding format, which is exposed there. I think there are some traits in convert that could be stabilized, but they aren't ready yet (and wouldn't help your case).

Upon further reflection, I realized it would probably make more sense for the implementations of these conversion traits to live in wasm-bindgen, rather than the ecosystem crates I was talking about.

We would like to avoid this for various reasons:

• Maintenance burden.
• Difficult to filter who gets an implementation and who doesn't.
• Cargo.lock pollution for a highly foundational crate. See https://github.com/rust-lang/cargo/issues/10801.

It's more logical for the conversion layer (wasm-bindgen) to specify how to convert types, as opposed to the types themselves. This is how pyo3 works, and it sort of follows the convention established by the serde ecosystem.

AFAIK this is not how Serde works. Serde only implements Std types, everybody else has to add their own serde crate feature and implementation. So we are actually following the convention of the Serde ecosystem. Or did I misunderstand something here?

---

I think the solution here is to enable your use-case in a stable way that doesn't require exposing the internal encoding format. Probably via the #[wasm_bindgen] macro. Obviously this would require significant design work.