feat: swc cross version compatibility

[yslpn]

Support Enhanced Cross-Version Compatibility

Description

Adopts the enhanced compatibility patterns introduced in @swc/core v1.15.0 according to the SWC Plugin Compatibility Guide.

Motivation

Starting from @swc/core v1.15.0, SWC introduced enhanced compatibility for Wasm plugins. This allows plugins to work with newer @swc/core versions that introduce new AST node types, as long as the code doesn't use those new features.

Benefits for users:

• Can upgrade @swc/core without waiting for plugin updates
• Plugin works until new features are actually used
• Clear error messages when incompatibilities are encountered

Benefits for maintainers:

• Reduced maintenance burden
• Less frequent updates required
• Better user experience

This PR implements the required changes to support this new compatibility mode.

Changes

• Added swc_ast_unknown cfg flag in .cargo/config.toml
• Added build.rs to declare the cfg flag (prevents Rust 1.80+ warnings)
• Explicitly enumerated all known AST enum variants in pattern matches
• Added panic_unknown_node() helper for informative error messages
• Added 5 enum coverage tests to ensure all known variants are handled

Breaking Changes

• No

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.24%. Comparing base (4d28b7f) to head (e1a5c4f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #185      +/-   ##
==========================================
+ Coverage   92.17%   93.24%   +1.06%     
==========================================
  Files           8        8              
  Lines        1355     1362       +7     
==========================================
+ Hits         1249     1270      +21     
+ Misses        106       92      -14     

Flag	Coverage Δ
unittests	93.24% <100.00%> (+1.06%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/ast_utils.rs	93.19% <100.00%> (+9.50%)	⬆️
src/builder.rs	98.90% <ø> (ø)
src/jsx_visitor.rs	88.33% <ø> (ø)
src/lib.rs	90.34% <ø> (ø)
src/macro_utils.rs	88.70% <100.00%> (+0.60%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[timofei-iatsenko]

Wow. Finally. I missed that news. BTW, for anyone landed on this issue - here is a blog post from kdy https://blog.swc.rs/2025-11-4-wasm-backward-compatibility and PR

Here’s a smoother, more neutral, and clearer version, keeping a technical review tone and tightening the language a bit:

However, I have a few questions regarding this PR.

To be honest, the implementation looks somewhat AI-generated, which makes me want to better understand your reasoning and level of familiarity with this code.

1. From the SWC docs, I couldn’t clearly determine whether we need to explicitly handle the Unknown variant in cases where we are not doing exhaustive pattern matching. My understanding is that if we are only interested in specific syntax types and handle everything else with a simple fallback like:

   _ => None,

   then there is no need to expand this into something like:

   // Known JSXAttrValue variants that we don't support
   JSXAttrValue::JSXElement(_) => None,
   JSXAttrValue::JSXFragment(_) => None,
   JSXAttrValue::JSXExprContainer(_) => None, // Non-Expr variants
   
   #[cfg(swc_ast_unknown)]
   _ => panic_unknown_node("JSXAttrValue", val),

   In this case, the plugin should continue to work correctly even if new syntax is introduced — it would simply ignore what it doesn’t care about and still extract the required data.

2. If the above understanding is correct, then this explicit arm matching seems unnecessary, and the changes could be reverted without affecting compatibility or correctness.

3. If my understanding is incorrect and we do need to handle this explicitly, are we sure that having panic_unknown_node in the our code is the right approach? From what I can tell, SWC already handles errors thrown during plugin execution and presents them to the user in a reasonably friendly way, so this may be redundant.

[timofei-iatsenko]

Regarding point number 1, here is a PR for swc-managed plugins https://github.com/swc-project/plugins/pull/543/changes#diff-2646e2761a3f0ab6176eeb126edd0f3a1cad1cc1534ebe0e5336d3686b24b99e

From a quick view, they added #[cfg(swc_ast_unknown)] arm only were there was an exhaustive pattern matching (no _ arm before). So this somewhat proving my concern.

[timofei-iatsenko]

@yslpn superseded by #187

Thanks for the pointing to that upgrade. In turn we need just to rise this flag and nothing else, so i did this in my PR. Thanks again for the job.