rules_swc
rules_swc copied to clipboard
aspect-build
chore: update SWC to latest
@jbedard I'm taking another pass at getting this working.
I checked my repro that I filed upstream in https://github.com/swc-project/swc/issues/8265 and it's working correctly now: https://github.com/alexeagle/swc_8265_repro/commit/f1b6331f8fee3ad85d418fb1d5a5e20408b7ab3a
however we still get a wrong golden file here when trying to upgrade.
@realtimetodie are you still around and interested in this project?
Our guess is that https://github.com/swc-project/swc/commit/7dfdc1221890d373d2e6caf52bc8dee8c20765ca#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.
I've updated the repro to align more with how bazel lays out the bazel-bin + sandbox directories to reproduce the issue: https://github.com/alexeagle/swc_8265_repro/commit/16bfa92286bdafe5dc48ead53c9b4177ce603fbb
Yay a fix has landed upstream https://github.com/swc-project/swc/pull/8757
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????
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 https://github.com/swc-project/swc/issues/9344
@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.
@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.