dicej opened issue #4303:
Per https://github.com/bytecodealliance/wit-bindgen/issues/259, I'm interested in upgrading the
wasmtimedependency inwit-bindgen, and that has raised a more general question, which I'd like to ask here:What's the vision for code which previously used module linking and will eventually need to transition to the component model? Will there be a simple recipe to follow, or will big (e.g. architectural) changes be necessary?
Whatever that vision is, I'd be interested to help implement it if there are opportunities to do so without distracting from the work already in progress.
dicej commented on issue #4303:
I hijacked today's wasmtime project meeting to discuss this and had a very enlightening conversation with @alexcrichton and @fitzgen about it. Here are my takeaways:
- Users of module linking should stick with pre-0.36
wasmtimefor the time being. Although it's technically possible to migrate to the component model already (i.e.wasmtimehas enough of the building blocks to make module linking work), the rest of the ecosystem has not caught up and can't catch up until more foundation work is done, and trying to use it in this state would not be worth the trouble.- There are a few specific opportunities to help with that foundation work now, and once that's done the ecosystem work will be very parallelizeable; i.e. many more opportunities will arise. I've volunteered to help with this, and Alex and Nick are going to open issues to track a couple of the foundation work items.
- The long-term vision for linking modules will be component-oriented, e.g.
wasmtime_wasi::add_to_linkerwould take acomponent::Linker.@alexcrichton perhaps you could clarify the last point, since I'm not sure I understood it. Would there be two variants of
add_to_linker, one for modules and one for components? Or would bothLinkertypes implement a trait so thatadd_to_linkercould be generic? Or wouldcomponent::Linkersimply replace the moduleLinkerand subsume the latter's functionality such that instantiating a module is the same as instantiating a trivial component containing a single module?
alexcrichton commented on issue #4303:
Sure yeah, my current thinking is that
wit-bindgenwill only generate oneadd_to_linkerfunction which will only work with components, not with core wasm modules. Much of the component model only makes sense in the context of the component model itself (e.g. async, resources, streams, etc) so I don't think it will be possible to have a full-featured generated for "just" core wasm. This means that in the long run support for running raw core wasm files will likely be dropped fromwit-bindgensince it'll work primarily at the ocmponent layer.
alexcrichton commented on issue #4303:
Also, for concrete work items, I'm trying to keep the main tracking issue up-to-date and the "Separate work items" category should all be issues that are standalone (ish) and possible to implement in parallel. (although I still wouldn't classify any of them as "easy")
dicej commented on issue #4303:
I think the original questions here have been addressed, so I'm going to close this. Thanks for your help, Alex!
dicej closed issue #4303:
Per https://github.com/bytecodealliance/wit-bindgen/issues/259, I'm interested in upgrading the
wasmtimedependency inwit-bindgen, and that has raised a more general question, which I'd like to ask here:What's the vision for code which previously used module linking and will eventually need to transition to the component model? Will there be a simple recipe to follow, or will big (e.g. architectural) changes be necessary?
Whatever that vision is, I'd be interested to help implement it if there are opportunities to do so without distracting from the work already in progress.
Last updated: Dec 13 2025 at 19:03 UTC