slint-ui/slint · error

Unmapped WindowEvent field type

Error message

Unmapped WindowEvent field type `{other}`. Extend `map_event_field_type` in api/node/build.rs, and import the TS type it maps to in the generated module.

What it means

map_event_field_type maps WindowEvent field types to (TS type, JsWindowEvent field type) pairs when generating window-event.ts. This panic is a forward-compatibility guard: a variant gained a field whose Rust type has no mapping, and rather than emit an invalid interface the build fails with instructions to extend the map and import the corresponding TS type. The offending input is the unmapped Rust type string.

Solutions

1. Extend map_event_field_type in api/node/build.rs with a match arm mapping the new Rust type to (ts_type, js_field_type)
2. Import the mapped TS type in the generated window-event module as the error message instructs
3. If the type is generic or a path, resolve it to its concrete last segment before matching

When it happens

Trigger: Thrown at api/node/build.rs:464 when the library encounters an invalid state.

Common situations: See trigger scenarios.

AI-assisted analysis of slint-ui/slint@bb937076de (2026-09-16). Data as JSON: /api/errors/b5d7d568c8372ebd. Report an issue: GitHub.

Appendix: source

Thrown at api/node/build.rs:464

    write_jsdoc(&mut ts, "", &jsdoc_for(core.docs.as_slice(), napi.docs.as_slice()));
    let union = core_names.iter().map(|name| format!("    | {name}Event")).collect::<Vec<_>>();
    ts.push_str(&format!("export type WindowEvent =\n{};\n", union.join("\n")));

    write_if_changed(&generated_dir().join("window-event.ts"), &ts);
}

/// Map a `WindowEvent` field type to the TS type used in the generated interface, and to the
/// type the matching `JsWindowEvent` field must have.
fn map_event_field_type(rust_ty: &str) -> (&'static str, &'static str) {
    match rust_ty {
        "LogicalPosition" => ("Point", "SlintPoint"),
        "LogicalSize" => ("Size", "SlintSize"),
        "PointerEventButton" => ("language.PointerEventButton", "JsPointerEventButton"),
        "SharedString" => ("string", "String"),
        "f32" => ("number", "f64"),
        "bool" => ("boolean", "bool"),
        other => panic!(
            "Unmapped WindowEvent field type `{other}`. Extend `map_event_field_type` in \
             api/node/build.rs, and import the TS type it maps to in the generated module."
        ),
    }
}

/// The binding's own doc comment wins, because it's already written for JavaScript.
/// Otherwise the core enum's rustdoc is translated.
fn jsdoc_for(core_docs: &[String], napi_docs: &[String]) -> Vec<String> {
    if !napi_docs.is_empty() {
        return napi_docs.to_vec();
    }
    rustdoc_to_jsdoc(core_docs)
}

/// Turn rustdoc into JSDoc. Intra-doc links become their label, since the targets are Rust
/// paths, and everything from the first heading or fence on is dropped: that only ever
/// introduces a Rust example.

View on GitHub (pinned to bb937076de)