Stream: git-wasmtime

Topic: wasmtime / issue #13879 Decouple Component Model Async AB...

Wasmtime GitHub notifications bot (Jul 14 2026 at 19:32):

lexoliu opened issue #13879:

Motivation

We have a compile-only host tool that uses Wasmtime's compiler APIs to produce precompiled Component Model artifacts for a separate runtime. The artifacts need the Component Model Async ABI enabled, but the compiler process never instantiates or executes components asynchronously.

Today the component-model-async Cargo feature also enables Wasmtime's async feature:

component-model-async = [
  "async",
  "component-model",
  "wasmtime-component-macro?/component-model-async",
  "dep:futures",
]

The async feature in turn enables wasmtime-fiber and runtime. That couples async ABI compilation to fiber-based execution machinery even for a compiler-only binary.

This matters for a split deployment where:

• a host compiler precompiles components with Config::wasm_component_model_async(true);
• a separate no-std runtime deserializes those artifacts and supplies the execution machinery;
• the compiler should not need fiber/runtime support merely to generate compatible artifacts.

Current constraint

The async Component Model configuration methods and concurrency feature validation are gated only on feature = "component-model-async". As a result, enabling the parser/compiler feature also selects the runtime implementation.

Proposed feature boundary

Would Wasmtime accept a separate compile capability, for example:

component-model-async-compile = [
  "component-model",
  "wasmtime-component-macro?/component-model-async",
]

The existing component-model-async feature could remain the full execution feature, while the relevant Config::wasm_component_model_* methods and concurrency-support validation would be available when either the compile capability or the full runtime capability is enabled.

A local proof of concept with this split can precompile async Component Model artifacts without selecting wasmtime-fiber; the normal runtime configuration can deserialize and execute the resulting artifacts.

I am opening this issue before preparing a PR because the main question is ownership of the feature boundary: should async ABI compilation have its own Cargo feature, or should these compiler/configuration APIs instead be considered part of the base component-model feature?

Wasmtime GitHub notifications bot (Jul 14 2026 at 19:55):

lexoliu closed issue #13879:

Motivation

We have a compile-only host tool that uses Wasmtime's compiler APIs to produce precompiled Component Model artifacts for a separate runtime. The artifacts need the Component Model Async ABI enabled, but the compiler process never instantiates or executes components asynchronously.

Today the component-model-async Cargo feature also enables Wasmtime's async feature:

component-model-async = [
  "async",
  "component-model",
  "wasmtime-component-macro?/component-model-async",
  "dep:futures",
]

The async feature in turn enables wasmtime-fiber and runtime. That couples async ABI compilation to fiber-based execution machinery even for a compiler-only binary.

This matters for a split deployment where:

• a host compiler precompiles components with Config::wasm_component_model_async(true);
• a separate no-std runtime deserializes those artifacts and supplies the execution machinery;
• the compiler should not need fiber/runtime support merely to generate compatible artifacts.

Current constraint

The async Component Model configuration methods and concurrency feature validation are gated only on feature = "component-model-async". As a result, enabling the parser/compiler feature also selects the runtime implementation.

Proposed feature boundary

Would Wasmtime accept a separate compile capability, for example:

component-model-async-compile = [
  "component-model",
  "wasmtime-component-macro?/component-model-async",
]

The existing component-model-async feature could remain the full execution feature, while the relevant Config::wasm_component_model_* methods and concurrency-support validation would be available when either the compile capability or the full runtime capability is enabled.

A local proof of concept with this split can precompile async Component Model artifacts without selecting wasmtime-fiber; the normal runtime configuration can deserialize and execute the resulting artifacts.

I am opening this issue before preparing a PR because the main question is ownership of the feature boundary: should async ABI compilation have its own Cargo feature, or should these compiler/configuration APIs instead be considered part of the base component-model feature?

Wasmtime GitHub notifications bot (Jul 14 2026 at 19:56):

lexoliu edited issue #13879:

[DELETED]

Last updated: Jul 29 2026 at 05:03 UTC