Stream: wasmtime

Topic: Running Wasm core modules, not components, for WASIp2/p3

Jim Teichgräber (Jul 02 2026 at 11:54):

Wasmtime, understandably, does not currently "automagically" convert Wasm core modules in to Wasm components (i.e. run the equivalent of wasm-tools component new), when core modules are passed to wasmtime run.

This is very understandable, given that wasmtime run needs to support WASI p1 core modules, and WASI p2/p3 components, so it presumably couldn't simply just always try to convert any passed core module to a component, even if that was desired.

But I'd like to ask, or possibly start a discussion on that last, part: whether it might be desired to be able to directly run core Wasm modules that simply use WASI >=0.2 APIs with "normal" core imports and exports.

Right now, the "hard" requirement for "componentization" (e.g. by wasm-tools) makes a lot of sense in terms of separation of concerns, of course, but it also means that compilers/toolchains targetting Wasm have to choose between:

1. Output Wasm component binaries, essentially duplicating much of the work done by the wit-component crate to encode canon lift/lower, and higher-level WIT types directly into the binary.
2. Same as 1., but instead of implementing this themselves, hook into this existing functionality in some way, either by using the wit-component crate (potentially through some FFI, depending on the implementation language), or by directly depending on the wasm-tools package as a runtime dependency to call wasm-tools component new for the user.
3. Don't do 1. or 2., simply output a Wasm core module as a binary and let the user deal with it.

Rust's wasm32-wasip2 target, being implemented in Rust, has an easy time using approach 2. (in wasm-component-ld, iiuc). Other implementations all have to make this call, and involve quite a bit of plumbing effort to make it easy for users, by implementing 1. or 2., or resort to 3. in case they cannot afford that effort.

If Wasmtime was able to run core modules even in this case, that problem would be solved, and the expectation "simple binary output by compiler (without external tooling) is runnable by vm" would be fully restored, without these any hack to stitch together tools, like both solutions 1. and 2. feel like. Of course, the only thing that would happen in reality is the hack moves to Wasmtime, which is ugly in itself, but perhaps less ugly than having to re-implement this/re-make this decision in every toolchain?

I'm curious about what people think of this. I've looked through the chat, as well as the issue tracker and couldn't really find an existing explicit discussion about this, sorry if I missed anything there.

Till Schneidereit (Jul 02 2026 at 12:46):

as I see it, there are two key problems with this approach:

1. the componentization applied by wit-component / wasm-component-ld relies on information in a custom section. Those are meant to be optional; stripping them is permissible at any step. That's okay as long as there is tight control of the pipeline between building a core module and componentizing it, as is the case right now. With this proposal, that would evaporate, and I'm not sure how we could do anything about it. This also means that your option (3) doesn't really exist: toolchains do have to provide more information about the interface than just emitting a core module with core module imports/exports implementing the canonical ABI. That's already the case, but will be even more so with more sophistication over time, such as direct support for WasmGC, or more wide-spread use of lifting/lowering options such as choosing different string encodings.
2. the component model very deliberately doesn't privilege host-builtin APIs over those provided by other components: any component import can be provided by another component just as well as the runtime environment. With this proposal, we'd give up on that in practice, I think: we'd say "toolchain vendors, focus on use cases where the runtime environment provides everything that's needed to run your outputs, and ignore linking of components.

Additionally, I would also gently push back on the framing of this as "hacks": same as a compiler targeting native code outputs .o, with the linker turning that into actual executables, I don't think there's anything particularly noteworthy about toolchains needing to wrap outputs into another layer. As you say, general-purpose tools do exist for this, and I think toolchains adopting wasm-component-ld instead of rolling their own linker would be perfectly fine as a common practice. They'd still have to provide the information needed for the linker to do its job, but as said above, that is pretty fundamental

Alex Crichton (Jul 02 2026 at 14:05):

In addition to the points that Till brought up, I would say that there's a strong distinction to be made between tooling conventions and what Wasmtime accepts at runtime. There's currently no standard for what wasm-tools component new does. There's no review process beyond the repository itself, there's no venue for standardization, etc. This is all exactly what the component-model is supposed to serve and best serves. The closest approximation to this is the BuildTargets.md proposal which is not yet complete. Even then that would only be one possible piece of the puzzle, and my point is that if Wasmtime were to ever accept a core module as a substitute for a component there would need to be a standard definition of what it meant to do so

Jim Teichgräber (Jul 02 2026 at 14:58):

Thank you both for your time in considering this and responding!

First of all, I'm reading my message back again and have to agree that phrasing those as hacks, esp. without "", wasn't ideal. Separating concerns in this way is a perfectly valid approach of course, I didn't mean to suggest otherwise.

Even though I came across wasm-component-ld, which obviously references linking, I hadn't considered the analogy to static linking of native binaries more deeply. I think there are some differences in the practicalities - most importantly that it's easy to assume any working system already has a linker installed - but it's a good way to think about it.

All the points you bring up make a lot of sense, and seem only really solvable with actual hacks, like simply assuming the existence of those custom sections, or some "implicit" standard for the input format, which both seem like hairy options.

Thanks again : )

Last updated: Jul 29 2026 at 05:03 UTC