I actually upgraded my team's Jest config to use https://github.com/Brooooooklyn/swc-node https://github.com/Brooooooklyn/swc-node a few weeks ago. However, our

I actually upgraded my team's Jest config to use https://github.com/Brooooooklyn/swc-node https://github.com/Brooooooklyn/swc-node a few weeks ago. However, our Jenkins CI agents run RHEL7, and neither of the Linux binary targets would run. The `x64-gnu` binary needed a `GLIBC_2_23` symbol when only 2.18 was available, and the `x64-musl` binary had no `musl-libc` on the machine. I don't own the Jenkins agents, so I couldn't install other deps myself. I ended up building `musl-libc` from source on another RHEL7 agent, committed the `.so` to our repo, and added that to the `LD_LIBRARY_PATH` in our Jenkinsfile, and actually got that working. I did see some mentions that Rust could build to target an older GLibc ( https://kobzol.github.io/rust/ci/2021/05/07/building-rust-binaries-in-ci-that-work-with-older-glibc.html https://kobzol.github.io/rust/ci/2021/05/07/building-rust-bi... ), so I'm curious if Next is going to use copies of SWC built that way for better compat or if it will require more workarounds on my part. I can definitely see shipping a WASM version as a great workaround to those sorts of compat issues.