Stream: wit-bindgen

Topic: conversion to-and-from encoding formats

Yosh Wuyts (Dec 08 2025 at 15:17):

Hey, I've got a code organization question: so wit-bindgen today is fine with taking in WIT and producing bindings to some other language. But what if we wanted to do the reverse as well? E.g. parse some data format and produce WIT from that?

• Would that fit the wit-bindgen repository model?
• If so, what would the right naming convention for that be?
• What if we didn't just want to generate WIT from that, but also a shim component that does the translation. Would that fit?

Yosh Wuyts (Dec 08 2025 at 15:19):

I'm asking because I think of wit-bindgen as a swiss army knife of format conversions. The ideal place for programming language bindings generations is probably with the languages themselves. But when we're working with data formats and markup languages instead of programming languages, it's less clear who should own that. And wit-bindgen seems a great place for that.

Till Schneidereit (Dec 08 2025 at 15:57):

to the degree we have any precedent for this question, it'd point towards wasm-tools being the right place: the only WIT-generating functionality I'm aware of right now is going from a .wasm file to a .wit file using `wasm-tools component wit

Till Schneidereit (Dec 08 2025 at 15:58):

IIUC you're thinking of introducing sort of the inverse of wit-bindgen, which would take something else and emit WIT representing an interface expressed in that something? Where the something could presumably be some other IDL, or a source project to reflect on?

Yosh Wuyts (Dec 08 2025 at 16:02):

I feel like today we already have component equivalents of the bindgen crate (Rust -> C). What I'm wondering about is how to add crates that do the equivalent to the cbindgen crate (C -> Rust). So yes, inverse is correct!

Yosh Wuyts (Dec 08 2025 at 16:04):

Till Schneidereit said:

to the degree we have any precedent for this question, it'd point towards wasm-tools being the right place: the only WIT-generating functionality I'm aware of right now is going from a .wasm file to a .wit file using `wasm-tools component wit

hmmm, that doesn't feel as intuitive to me. For me wasm-tools cares about Wasm-only things. Where .wasm to .wit feels like a Wasm-to-Wasm conversion.

Alex Crichton (Dec 08 2025 at 16:04):

Do you mean to swap the Rust<->C directions of cbindgen/bindgen? Or put another way, are you wondering if we can have #[wit_bindgen] which looks like #[wasm_bindgen]?

Yosh Wuyts (Dec 08 2025 at 16:06):

haa, okay let me make it more concrete: right now the main thing I'm looking at is a JSON Schema -> WIT conversion. But in the future that might be neat to extend to maybe generate the conversion code too, as a standalone components.

Yosh Wuyts (Dec 08 2025 at 16:07):

Alex Crichton said:

Do you mean to swap the Rust<->C directions of cbindgen/bindgen? Or put another way, are you wondering if we can have #[wit_bindgen] which looks like #[wasm_bindgen]?

Though unrelated to what I'm looking at right now, I'd love this too. Just not something I have the bandwidth for right now.

Alex Crichton (Dec 08 2025 at 16:08):

Do you mean like converting openapi to wit?

Yosh Wuyts (Dec 08 2025 at 16:09):

yeah that's very similar

Alex Crichton (Dec 08 2025 at 16:09):

What do you mean by "generate the conversion code"? Do you mean generate the thing that converts openapi to wit?

Yosh Wuyts (Dec 08 2025 at 16:10):

In Wassette we have component2json which matches the polarity of everything else in wit-bindgen. What I'm looking at building is the reverse

Yosh Wuyts (Dec 08 2025 at 16:11):

Alex Crichton said:

What do you mean by "generate the conversion code"? Do you mean generate the thing that converts openapi to wit?

the first pass would be to convert the schema. So you have a JSON Schema and convert it to a .wit. The second pass would be to generate a parser component, which can take in JSON Schema messages, deserialize them, and invoke methods in a linked component.

Yosh Wuyts (Dec 08 2025 at 16:13):

That second pass is entirely out of scope for me for now tho. I'm mainly interested in mechanically translating one schema definition to another so the interfaces line up.

Yosh Wuyts (Dec 08 2025 at 16:13):

Oh I guess that's similar to webidl2wit

Alex Crichton (Dec 08 2025 at 17:44):

To the best I understand this it all feels roughly outside of wit-bindgen's wheelhouse. Conversion from thing-to-wit is sort of a wasm-tools level thing, and then generating actually full binaries isn't really what wit-bindgen does (which instead just generates source code). So at least to me this naively seems like a different tool which doesn't fit in necessarily with wit-bindgen

Christof Petig (Dec 09 2025 at 12:28):

I hacked rust-bindgen to read C headers and output wit files. Since I didn't spend too much time it is incomplete (no function declarations, not all data types) but should be a good starting point for experiments: https://github.com/cpetig/rust-bindgen

Landon James (Dec 10 2025 at 03:37):

Not exactly what you are asking about, but I also did a hacky thing in this vein earlier this year (that I never got around to finishing). In the smithy-wasm repo I generate wit files from the Smithy IDL (well really from the compiled Smithy JSON AST).

I work on the AWS Rust SDK and all of our service APIs are defined in Smithy. My eventual goal is to also generate Rust code to implement WASM versions of the SDK clients for all of our services. Never got time to move beyond the WIT generation though.

Last updated: Jan 09 2026 at 13:15 UTC