wasmtime / issue #14859 The wasmtime CLI doesn't support ... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #14859 The wasmtime CLI doesn't support ...

Wasmtime GitHub notifications bot (Oct 19 2026 at 20:46):

wasmtime run and wasmtime serve never call add_named_to_linker, so a component with a labelled WASI import, e.g. import env2: wasi:cli/environment@0.3.2; or a labelled wasi:http/client, fails to link:
component imports instance `env2`, but a matching implementation was not found in the linker
Labelled exports don't work either: export h: wasi:http/handler@0.3.0 under serve fails with a misleading no exported instance named 'wasi:http/incoming-handler@0.2.12', and a labelled wasi:cli/run export under run with no exported instance named 'wasi:cli/run@0.2.12'.

Some possible options:

bind every labelled WASI import to the default context (maybe behind something like -S named-imports),

later, allow per-label configuration (--env/--dir),

for exports, fall back to the unique export that implements the expected interface.

Is this something the CLI should support, and if so, which direction would you prefer?

Wasmtime GitHub notifications bot (Oct 19 2026 at 21:00):

alexcrichton commented on issue #14859:

This is by design. Do you intend for this to be a feature request?

Wasmtime GitHub notifications bot (Oct 19 2026 at 21:05):

jrandolf commented on issue #14859:

I don’t have a concrete need for the CLI to bind labelled imports itself. But a labelled import fails with the generic “matching implementation was not found” (and also labelled exports). So preferably we either say explicitly that the CLI doesn’t support labelled (implements) imports/exports, in the error and/or docs, or we just make it work, e.g. by binding labelled WASI imports to the default context. I’m happy to send a PR for whichever you prefer.

Wasmtime GitHub notifications bot (Oct 19 2026 at 21:19):

alexcrichton commented on issue #14859:

Personally I'd err on the side of not doing anything here and just leaving this open. It's probably a nontrivial bit of infrastructure to add better error messages here at minimum and it's not clear that it's necessarily worth it just yet. Guests have to opt-in to named imports so the situation that this might arise is quite niche IMO. I don't think it makes sense to just bind to the default context because that sort of defeats the purpose of named imports in the first place

Last updated: Oct 31 2026 at 23:03 UTC