Bump swc

[mischnic]

Closes #9632
Closes #9607

There's a major breaking change, the LHS of assignments is now a special enum.

There's one place which I haven't been able to fix yet. Putting this up in case someone else wants to bump swc sooner rather than later for some reason

[mischnic]

Even in release builds, there is a segfault now in the EnvReplacer, the stack trace does many fold_expr -> fold_bin_expr -> fold_expr -> .... Happens on this file, which has a string concatenation expression containing 750 +: https://github.com/highlightjs/highlight.js/blob/105a11a13eedbf830c0e80cc052028ceb593837f/src/languages/isbl.js

Usually, this is only a problem (and has happened for a long time) in non-release builds.

But only on Linux and Windows, macOS works fine.

[mischnic]

The same asset also works fine in a standalone Rust projects (with the exact code as the JSTransformer, just without the Node process).
So I guess the stack occupied by Node plus the recursion in swc triggers the crash, and with just Rust the stack space is enough. And macOS probably also has more stack

[marcins]

The same asset also works fine in a standalone Rust projects (with the exact code as the JSTransformer, just without the Node process). So I guess the stack occupied by Node plus the recursion in swc triggers the crash, and with just Rust the stack space is enough. And macOS probably also has more stack

Not really an area I have any experience in, but a quick search shows that is possible to increase the stack size with some linker flags: https://www.reddit.com/r/rust/comments/872fc4/how_to_increase_the_stack_size/

Is that worth experimenting with?

EDIT: read something else that mentioned threads on linux specifically have a smaller stack, maybe we need to increase the Rayon thread stack size (that's where this code is running, right?): https://docs.rs/rayon/latest/rayon/struct.ThreadPoolBuilder.html#method.stack_size

[mischnic]

I want to try bisecting which swc version introduced this, because not much changed regarding the AST depth

So increasing the stack size would maybe just be a workaround until some future version.

[mischnic]

As it turns out, this also occurs in Deno and Turbopack: swc-project/swc#8840

[jondlm]

@devongovett when you have a moment could you review this PR? Normally I wouldn't bother with a ping but it's currently a blocker for us at Stripe. I think it's good to go it just needs an approving review.

[marcins]

Found a new bug that affects non-scope hoisted builds, needs to be fixed before merging.

[marcins]

Just sharing what I shared in Discord here, it seems that the change arround AssignPatProp means that after visiting here it will visit into fold_binding_intent, this results in a duplicate export being added for exports of the form export const { Foo } = bar; in non-scope hoisting mode - this breaks at runtime.

This change fixed the issue for me, but not sure if there's some edge case that it might not be correct for. It would be good to start with a failing integration test.

diff --git a/packages/transformers/js/core/src/modules.rs b/packages/transformers/js/core/src/modules.rs
index 65235f3c3..bd13d10b6 100644
--- a/packages/transformers/js/core/src/modules.rs
+++ b/packages/transformers/js/core/src/modules.rs
@@ -598,9 +598,11 @@ impl Fold for ESMFold {
         Expr::Ident(node.key.id.clone()),
         DUMMY_SP,
       );
+      node
+    } else {
+      node.fold_children_with(self)
     }
 
-    node.fold_children_with(self)
   }
 
   modules_visit_fn!(fold_function, Function);

[mischnic]

@marcins @jondlm I fixed that problem, there's a new dev release published at [email protected] if you want to test it again.

https://github.com/parcel-bundler/parcel/actions/runs/9077140040/job/24942042946

[marcins]

I've tested our dev server and production builds of Jira and they appear to be working correctly now! 🎉

[jondlm]

We also tested it and it's working for us. Thank you so much @mischnic & @marcins!