wasmerio/wasmer · error

The type is not yet supported in the JS Global API

Error message

The type is not yet supported in the JS Global API

What it means

Global::from_value for the JS backend only maps I32, I64, F32, F64 to JS descriptor/value pairs; all other Value variants (e.g. V128, FuncRef, ExternRef) hit `unimplemented!`. The JS WebAssembly.Global API surface supported by this binding does not cover those types yet.

Source

Thrown at lib/api/src/backend/js/entities/global.rs:47

        val: Value,
        mutability: Mutability,
    ) -> Result<Self, RuntimeError> {
        if !val.is_from_store(store) {
            return Err(RuntimeError::new(
                "cross-`WasmerEnv` values are not supported",
            ));
        }
        let global_ty = GlobalType {
            mutability,
            ty: val.ty(),
        };
        let descriptor = js_sys::Object::new();
        let (type_str, value) = match val {
            Value::I32(i) => ("i32", JsValue::from_f64(i as _)),
            Value::I64(i) => ("i64", JsValue::from_f64(i as _)),
            Value::F32(f) => ("f32", JsValue::from_f64(f as _)),
            Value::F64(f) => ("f64", JsValue::from_f64(f)),
            _ => unimplemented!("The type is not yet supported in the JS Global API"),
        };
        // This is the value type as string, even though is incorrectly called "value"
        // in the JS API.
        js_sys::Reflect::set(&descriptor, &"value".into(), &type_str.into())?;
        js_sys::Reflect::set(
            &descriptor,
            &"mutable".into(),
            &mutability.is_mutable().into(),
        )?;

        let js_global = WebAssembly::Global::new(&descriptor, &value).unwrap();
        let vm_global = VMGlobal::new(js_global, global_ty);

        Ok(Self::from_vm_extern(store, VMExternGlobal::Js(vm_global)))
    }

    pub fn ty(&self, _store: &impl AsStoreRef) -> GlobalType {
        self.handle.ty

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

1. Restrict globals to i32/i64/f32/f64 values on the js backend
2. Convert reference globals to host-side storage (e.g. externref tables or host functions) instead of JS Globals
3. Upgrade wasmer — newer builds may map ref types to WebAssembly.Global of type funcref/externref
4. Add a validation step rejecting non-numeric global Values on the js backend before calling from_value

Example fix

// before
match val {
    Value::V128(_) => unimplemented!("..."),
}
// after
match val {
    Value::V128(_) => Err(GlobalError::Unsupported("v128 globals are not supported on the JS backend")),
    _ => /* existing numeric path */,
}

// validate global value type before creating a JS-backed Global
fn global_value_js_supported(v: &Value) -> bool {
    matches!(v, Value::I32(_) | Value::I64(_) | Value::F32(_) | Value::F64(_))
}

fn is_numeric_global_value(v: &Value) -> bool {
    matches!(v, Value::I32(_) | Value::I64(_) | Value::F32(_) | Value::F64(_))
}

When it happens

Trigger: Creating or importing a wasmer Global from a Value::V128 (SIMD) or a reference-typed value (funcref/externref) through the js backend's Global::from_value path — e.g. embedder code building globals programmatically or a wasm module exporting/importing a v128 or ref global in a browser/Node runtime.

Common situations: Wasm modules using reference types (reftypes) or SIMD globals compiled to run on wasmer-js; embedders passing Values other than the four numeric types when creating globals in the browser; parity gaps with the native backend.

Related errors

• unimplemented operator {operator:?}
• Cannot write non-scalar value as bytes
• Cannot read non-scalar value from memory
• Cannot get size of reference type
• Cannot store reference type

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