swc-project/swc · error
failed to handle: {s}
Error message
failed to handle: {s} What it means
The wasm (browser) HTML binding mirrors binding_html_node's util.rs: every operation runs inside catch_unwind inside try_with_handler, and a panic whose payload is a String is converted to 'failed to handle: {s}' and returned through to_pretty_error to JS. It marks an internal panic in the wasm-compiled swc HTML compiler, not a user diagnostic.
Source
Thrown at bindings/binding_html_wasm/src/util.rs:27
let cm = Lrc::new(SourceMap::new(FilePathMapping::empty()));
try_with_handler(
cm.clone(),
HandlerOpts {
skip_filename: false,
..Default::default()
},
|handler| {
//
let result =
std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| op(&cm, handler)));
let p = match result {
Ok(v) => return v,
Err(v) => v,
};
if let Some(s) = p.downcast_ref::<String>() {
Err(anyhow!("failed to handle: {s}"))
} else if let Some(s) = p.downcast_ref::<&str>() {
Err(anyhow!("failed to handle: {s}"))
} else {
Err(anyhow!("failed to handle with unknown panic message"))
}
},
)
.map_err(|e| e.to_pretty_error())
}
View on GitHub (pinned to d7d7434666)
Solutions
- Capture {s} from the thrown error - it names the internal panic - and minimize the document
- Upgrade the wasm html binding package; internal panics are fixed upstream
- Run the same input through the napi binding or swc CLI to confirm it is input-dependent, not wasm-specific
- Wrap calls so a panic rejects a promise instead of crashing the page (wasm panics otherwise trap the module)
Example fix
// before
import { minify } from '...wasm';
const out = minify(html, opts);
// after: keep the module usable after a panic-derived error
let out;
try {
out = minify(html, opts);
} catch (e) {
reportBadInput(file, String(e));
continue;
} Defensive patterns
Strategy: try-catch
Try / catch
let out;
try {
out = minify(html, opts);
} catch (e) {
if (String(e).startsWith('failed to handle')) {
reportAndSkip(file, e); // internal panic: keep the worker alive
} else throw e;
} Prevention
- Run wasm HTML compilation inside a Web Worker so panic-derived errors never trap the main thread
- Version-pin the wasm html binding and smoke-test your HTML corpus on every upgrade
When it happens
Trigger: Calling the wasm HTML parse/minify APIs (e.g. @swc/wasm-based html bindings) in the browser/bundler on markup that panics the HTML compiler: malformed nesting, pathological attribute structures, or a swc_html_* regression in the vendored version.
Common situations: In-browser HTML minification of user-uploaded content; wasm build pipeline where one input kills the whole worker; version skew between the wasm package and expected HTML grammar.
Related errors
- failed to handle: {s}
- failed to handle with unknown panic message
- failed to handle with unknown panic message
- Minify command is not yet implemented
- failed to handle: {s}
AI-assisted analysis of swc-project/swc@d7d7434666 (2026-08-16).
Data as JSON: /api/errors/94528e135893c33e.
Report an issue: GitHub.