es/minifier: unused class elimination removes superclass validation

Describe the bug

extract_class_side_effect preserves only explicit effects of the superclass expression. Evaluating a class also validates whether its heritage is null or a constructor; the side-effect-free numeric expression 1 fails that validation. Removing the class removes a catchable TypeError.

Input code

try { (class extends 1 {});console.log("no error") } catch(e){console.log(e.name)}

Config

Options used by the exact-source reproduction:

{
  "compress": {
    "defaults": false,
    "side_effects": true
  },
  "mangle": false,
  "module": false
}

Link to the code that reproduces this issue

Portable input and settings in SWC Playground

SWC Info output

Source build of swc_ecma_minifier 61.0.5, commit 246e6156ca14eaa07243ac8d9aa994c91c95cf3d, macOS arm64, Rust 1.96.0-nightly (f5eca4fcf 2026-04-09), Node v20.20.2.

The observed checkout and freshly fetched authoritative origin/main are the same commit. Fetch: git fetch --no-tags origin main, 2026-09-09T03:15:52Z, repository swc-project/swc. Reproduction was performed in a separate checkout of that fetched commit. Thus the cause remains on the default branch, not only in an older release.

For minify cases, the source harness follows the repository example: parse, resolve bindings, convert Terser compressor options, call optimize, apply fixer, emit, and execute original/output separately. Script-only behavior uses Script parsing. The playground carries portable source/settings; its published version is not evidence that the release matches the pinned source build. No implementation change was applied.

Expected behavior

Exit 0; stdout:

TypeError

Actual behavior

try{console.log("no error")}catch(e){console.log(e.name)}

Exit 0; stdout:

no error

Version

swc_ecma_minifier 61.0.5, 246e6156ca14eaa07243ac8d9aa994c91c95cf3d (also freshly fetched main).

Additional context

Responsible code: compress/optimize/util.rs:180.

The documented arithmetic-exception assumption does not cover ClassDefinitionEvaluation constructor validation. #5585 addresses coercion hooks and is a different boundary.

Proposed Scope

Keep class evaluation when superclass validity is not statically established. Preserve the known-valid null/no-heritage cases and preserve evaluation of the heritage expression exactly once. Do not replace constructor validation with only operand-effect extraction.

Limit the change to this semantic boundary and its regression coverage. No API expansion, dependency update, migration, deployment, or feature-flag rollout is required. Preserve the documented minifier assumptions; the reproduction does not require overriding builtin implementations.

Acceptance Criteria and Test Scenarios

• The primary input must print TypeError.
• class extends null remains a passing nonthrowing control.
• An arrow function as superclass must retain TypeError.
• A valid ordinary constructor superclass must remain valid without duplicate evaluation.
• Add regression coverage in the existing SWC-owned fixture/execution suites under crates/swc_ecma_minifier/tests/fixture/issues, or the existing tests/eval.rs API harness for the Evaluator case. Check exact execution/return values and valid generated syntax, not only snapshots.
• Initialize submodules, update fixture expectations only as needed, and rerun cargo test -p swc_ecma_minifier without UPDATE. Preserve passing controls above. Keep regression comments in English.

Duplicate search

No same-root open duplicate was found in bounded searches including "class" "extends" "TypeError" and related minifier terms. Similar issues were evaluated by root cause and transformation boundary.

Out of Scope

Unrelated rewrites, new user options, implementing other audit findings, and changing semantic assumptions.

This is a message for readers, not the author of this issue.

Please read no +1 before leaving a comment.