wasmerio/wasmer · error

The value `{:?}` is not yet supported in the JS Function API

Error message

The value `{:?}` is not yet supported in the JS Function API

What it means

`wasmer_value_to_js` converts wasmer `Value`s returned to JS (e.g. from exported function results). Most types are supported, including optional externrefs, but any remaining value kind reaching the catch-all arm — such as Value::FuncRef or Value::ExceptionRef — panics with this unimplemented message.

Source

Thrown at lib/api/src/backend/js/utils/convert.rs:90

    }
}

#[inline]
/// Convert a wasmer Value into a JsValue
pub fn wasmer_value_to_js(val: &Value) -> JsValue {
    match val {
        Value::I32(i) => JsValue::from_f64(*i as _),
        Value::I64(i) => JsValue::from_f64(*i as _),
        Value::F32(f) => JsValue::from_f64(*f as _),
        Value::F64(f) => JsValue::from_f64(*f),
        Value::V128(f) => JsValue::from_f64(*f as _),
        Value::ExternRef(Some(reference)) => match &reference.0 {
            crate::BackendExternRef::Js(reference) => reference.as_js_value(),
            #[allow(unreachable_patterns)]
            _ => unreachable!("a JS function received an externref from another backend"),
        },
        Value::ExternRef(None) => JsValue::null(),
        val => unimplemented!(
            "The value `{:?}` is not yet supported in the JS Function API",
            val
        ),
    }
}

impl AsJs for Value {
    type DefinitionType = Type;

    fn as_jsvalue(&self, _store: &impl AsStoreRef) -> JsValue {
        match self {
            Self::I32(i) => JsValue::from(*i),
            Self::I64(i) => JsValue::from(*i),
            Self::F32(f) => JsValue::from(*f),
            Self::F64(f) => JsValue::from(*f),
            Self::V128(v) => JsValue::from(*v),
            Self::FuncRef(Some(func)) => func.as_js().handle.function.clone().into(),
            Self::FuncRef(None) => JsValue::null(),

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

  1. Avoid exporting functions that return FuncRef/ExceptionRef on the js backend; return an i32 handle into a host registry instead
  2. Convert funcref results inside wasm to externref(JS) values before returning
  3. Run the module on a native backend if reference returns are required

Example fix

// before
Value::FuncRef(f) // returned from export -> panics
// after
Value::I32(registry.insert(f)) // return handle, JS fetches via host call
Defensive patterns

Strategy: type-guard

Validate before calling

fn js_returnable(v: &Value) -> bool {
    !matches!(v, Value::FuncRef(_) | Value::ExceptionRef(_))
}

Type guard

fn js_returnable(v: &Value) -> bool {
    !matches!(v, Value::FuncRef(_) | Value::ExceptionRef(_))
}

Try / catch

if !js_returnable(&result) {
    return Err(anyhow!("result type not supported by js Function API"));
}

Prevention

When it happens

Trigger: Calling an exported wasm function (or host function created via `new_with_env`/`new_with_env_async`) on the js backend where the result `Value` is a FuncRef or ExceptionRef (the catch-all `val =>` arm).

Common situations: Exports returning funcrefs to the browser; JS callers of a wasm module whose ABI includes reference-typed returns.

Related errors


AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/19dd7903921cef76. Report an issue: GitHub.