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
- Avoid exporting functions that return FuncRef/ExceptionRef on the js backend; return an i32 handle into a host registry instead
- Convert funcref results inside wasm to externref(JS) values before returning
- 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
- Keep exported functions returning numeric/externref types only
- Never return FuncRef/ExceptionRef from exports in browser builds
- Audit module exports with Module::info or a wasm parser before deploying to JS
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
- The type `{:?}` is not yet supported in the JS Function API
- The {val:?} is not yet supported
- ExceptionRefs are not yet supported in the JS Function API
- module info requires the wasm-types-polyfill feature
- Table.copy is not natively supported in Javascript
AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01).
Data as JSON: /api/errors/19dd7903921cef76.
Report an issue: GitHub.