chore: update SWC to latest

[alexeagle]

No description provided.

[alexeagle]

@jbedard I'm taking another pass at getting this working.

I checked my repro that I filed upstream in swc-project/swc#8265 and it's working correctly now:
alexeagle/swc_8265_repro@f1b6331

however we still get a wrong golden file here when trying to upgrade.

[alexeagle]

@realtimetodie are you still around and interested in this project?

Our guess is that swc-project/swc@7dfdc12#diff-80747e5885ec3975aab81e2ada0a9d27f3319dc0fb45fa38415e19e9aab629eaR224-R232 is only resolving one hop of the symlink that swc sees for the input file, but there are actually two hops under Bazel. So my original repro wasn't sufficient.

It has been a long time so I doubt we could ask the SWC maintainers to do another round-trip fixing this. I think one of us will have to try ourselves.

@jbedard volunteered today to find some time to make the repro more accurately lay out symlinks the same way Bazel does.

[jbedard]

I've updated the repro to align more with how bazel lays out the bazel-bin + sandbox directories to reproduce the issue: alexeagle/swc_8265_repro@16bfa92

[alexeagle]

Yay a fix has landed upstream swc-project/swc#8757

[alexeagle]

ugh @jbedard we are still getting

< const _moduleA = require("../../../../../../.cache/bazel/_bazel_runner/4b45c25630ed5c5c6ea70d3e83a5966d/sandbox/linux-sandbox/42/execroot/aspect_rules_swc/examples/paths/src/modules/moduleA");
INFO: From Testing //examples/paths:test_0_test:
---
> const _moduleA = require("./modules/moduleA/index");
FAIL: files "examples/paths/src/index.js" and "examples/paths/expected.js" differ. 

WHY????

[Aghassi]

More for posterity but I'm chiming in here to note this is still an issue as of SWC 1.6.6. We came across it when trying to explore using webpack aliases for something which also requires jsc.paths. So ultimately we had to scrap that plan since it's fraught with sandbox escapes still.

I tried to file a bug with SWC, but I guess I didn't provide enough info and was auto closed swc-project/swc#9344

[alexeagle]

@jbedard and I discussed the simple answer to this is just stop using the sandbox by default. SWC actions don't benefit since they are always one-file-in with no dependencies, so there's no hermeticity check that it's adding for developers. I can green this up now.

[alexeagle]

@Aghassi specifically I think we just recommend

# Workaround SWC issue with symlinks
common --modify_execution_info=SWCCompile=+no-sandbox

I feel like we did this a year ago and then I forgot? But it's simple, no downsides, and we can stop fighting with this.

[alexeagle]

replaced by #272