Skip to content

The wasmtime CLI doesn't support labelled WASI imports or exports #14859

Open

Description

@jrandolf

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?

Activity

  1. alexcrichton commented on Oct 19, 2026

    @alexcrichton
    Member

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

  2. jrandolf commented on Oct 19, 2026

    @jrandolf
    ContributorAuthor

    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.

  3. alexcrichton commented on Oct 19, 2026

    @alexcrichton
    Member

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions