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

  1. Capture {s} from the thrown error - it names the internal panic - and minimize the document
  2. Upgrade the wasm html binding package; internal panics are fixed upstream
  3. Run the same input through the napi binding or swc CLI to confirm it is input-dependent, not wasm-specific
  4. 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

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


AI-assisted analysis of swc-project/swc@d7d7434666 (2026-08-16). Data as JSON: /api/errors/94528e135893c33e. Report an issue: GitHub.