swc-project/swc · error

unable to access unknown nodes

Error message

unable to access unknown nodes

What it means

This Babelify impl maps the unified SWC BinaryOp enum onto either a Babel BinaryExprOp or LogicalExprOp. The `#[cfg(swc_ast_unknown)]` wildcard arm is compiled only in builds that pass `--cfg=swc_ast_unknown` (the cfg SWC plugin builds use to make swc_ecma_ast enums non_exhaustive), and it panics if the operator value is a variant the linked swc_ecma_ast version does not define. As elsewhere, this signals that the AST was produced by a different swc version than the one compiled into the babelify call.

Source

Thrown at crates/swc_estree_compat/src/babelify/operators.rs:68

            BinaryOp::LShift => BinaryOpOutput::BinOp(BinaryExprOp::LeftShift),
            BinaryOp::RShift => BinaryOpOutput::BinOp(BinaryExprOp::RightShift),
            BinaryOp::ZeroFillRShift => BinaryOpOutput::BinOp(BinaryExprOp::UnsignedRightShift),
            BinaryOp::Add => BinaryOpOutput::BinOp(BinaryExprOp::Addition),
            BinaryOp::Sub => BinaryOpOutput::BinOp(BinaryExprOp::Subtraction),
            BinaryOp::Mul => BinaryOpOutput::BinOp(BinaryExprOp::Multiplication),
            BinaryOp::Div => BinaryOpOutput::BinOp(BinaryExprOp::Division),
            BinaryOp::Mod => BinaryOpOutput::BinOp(BinaryExprOp::Remainder),
            BinaryOp::BitOr => BinaryOpOutput::BinOp(BinaryExprOp::Or),
            BinaryOp::BitXor => BinaryOpOutput::BinOp(BinaryExprOp::Xor),
            BinaryOp::BitAnd => BinaryOpOutput::BinOp(BinaryExprOp::And),
            BinaryOp::LogicalOr => BinaryOpOutput::LogicOp(LogicalExprOp::Or),
            BinaryOp::LogicalAnd => BinaryOpOutput::LogicOp(LogicalExprOp::And),
            BinaryOp::In => BinaryOpOutput::BinOp(BinaryExprOp::In),
            BinaryOp::InstanceOf => BinaryOpOutput::BinOp(BinaryExprOp::Instanceof),
            BinaryOp::Exp => BinaryOpOutput::BinOp(BinaryExprOp::Exponentiation),
            BinaryOp::NullishCoalescing => BinaryOpOutput::LogicOp(LogicalExprOp::Nullish),
            #[cfg(swc_ast_unknown)]
            _ => panic!("unable to access unknown nodes"),
        }
    }
}

// Babel appears to just store all of these as a string. See
// AssignmentExpression.operator field. NOTE(dwoznick): I'm unsure if this is
// the correct way to handle this case.
impl Babelify for AssignOp {
    type Output = String;

    fn babelify(self, _ctx: &Context) -> Self::Output {
        match self {
            AssignOp::Assign => "=".into(),
            AssignOp::AddAssign => "+=".into(),
            AssignOp::SubAssign => "-=".into(),
            AssignOp::MulAssign => "*=".into(),
            AssignOp::DivAssign => "/=".into(),
            AssignOp::ModAssign => "%=".into(),

View on GitHub (pinned to 5176682b65)

Solutions

  1. Align swc versions: `cargo tree -i swc_ecma_ast` must show one version; update through swc_core
  2. Upgrade swc_estree_compat together with swc_ecma_ast so the new operator variant is mapped
  3. Rebuild plugin/wasm binaries against the host's swc release after upgrading
  4. Use catch_unwind around Program::babelify to fail per-file instead of aborting the process
Defensive patterns

Strategy: try-catch

Type guard

fn binary_op_known(o: &BinaryOp) -> bool {
    matches!(
        o,
        BinaryOp::Eq | BinaryOp::NotEq | BinaryOp::EqEqEq | BinaryOp::NotEqEq
        | BinaryOp::Lt | BinaryOp::LtEq | BinaryOp::Gt | BinaryOp::GtEq
        | BinaryOp::Add | BinaryOp::Sub | BinaryOp::Mul | BinaryOp::Div | BinaryOp::Mod
        | BinaryOp::BitOr | BinaryOp::BitXor | BinaryOp::BitAnd
        | BinaryOp::LogicalOr | BinaryOp::LogicalAnd
        | BinaryOp::In | BinaryOp::InstanceOf | BinaryOp::Exp | BinaryOp::NullishCoalescing
        | BinaryOp::LShift | BinaryOp::RShift | BinaryOp::ZeroFillRShift
    )
}

Try / catch

let out = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| program.babelify(&ctx)))
    .map_err(|_| anyhow::anyhow!("babelify failed: swc_ecma_ast version mismatch (unknown BinaryOp)"))?;

Prevention

When it happens

Trigger: Babelifying an expression whose BinaryOp variant arrived from a newer/older swc_ecma_ast — across a plugin ABI boundary, a mixed-version Cargo graph, or deserialized ASTs from another producer version.

Common situations: A new swc release adds an operator variant and older plugins/wasm binaries panic on ASTs from the upgraded host; duplicate swc_ecma_ast versions in the dependency tree; cached build artifacts surviving a swc upgrade.

Related errors

AI-assisted analysis of swc-project/swc@5176682b65 (2026-08-17). Data as JSON: /api/errors/5fed71f12d38f62f. Report an issue: GitHub.