Support generating just types & bindings

[sd2k]

Currently Gravity takes a Wasm file containing embedded WIT as input, and uses:

• the WIT to generate types & bindings for imports and exports
• the Wasm (embedded or inlined) to generate code to create a runtime & instantiated module to use those types and bindings

I have a different use case, where I want to just generate the bindings, and have the user provide their own Wasm bytes for compilation & instantiation later. I think this should be fairly easy; we could even still generate a factory that accepts arbitrary bytes rather than embedding them directly.

This would allow creation of reusable Go packages which represent a WIT interface without being tied to a specific implementation (the Wasm itself).

[sd2k]

One concern is that we would need to validate that the final Wasm did indeed conform to the initial WIT provided when generating the bindings, which is slightly annoying. I assume that is possible somehow though - the wasm-tools component targets subcommand seems to do that (using this function).

[blaine-arcjet]

I like this idea but I'm trying to figure out how it works with shared-nothing linking. Last I looked at the jco transpile logic, they required a WebAssembly Component file which is a .wasm that contains multiple "core" components. I don't think it accepted WIT files.

[sd2k]

Yep, just took at look at that command and you're right. I don't have a great mental model for how exactly that works in jco yet.

I do still think something like this makes sense though - I think the Bindgen/Resolve that we get back from wit_component::metadata::decode should contain everything we need to generate the bindings, but if the user only has a Wasm component then we would also need to strip/split it into separate modules which our generated bindings would load (or take as an input).

I wonder if we could do that in two stages (maybe two CLI subcommands, with third to do both at once):

• one which just needs the WIT and generates bindings + factories which must be passed the bytes of each Wasm module
• one which needs the component Wasm, splits it up into core modules, outputs them into named files, and generates a file which embeds them using //go:embed & provides prefabricated NewFactory functions which use the embedded bytes.

Quite a bit of work, but much of it would need doing to support more complex components anyways.