Using SWC packages and building SWC are separate decisions
SWC's installation guide documents prebuilt packages through @swc/cli and @swc/core. Our failed source build does not establish whether those packages suit an application. It does show that the checkout workflow did not complete in our sandbox.
SWC, short for Speedy Web Compiler, is a JavaScript and TypeScript compiler written in Rust. Its README describes libraries for Rust and JavaScript developers and points Rust users toward the parser. Application maintainers and compiler contributors therefore have different setup decisions to make.
What happened when we ran it
Our sandbox installed SWC commit b86e5c9 on October 10, 2026, in 14 seconds, recording 1 dependency and 496 MB on disk. Our SWC source build failed after 8 seconds, with exit 1. The test command failed with exit 1 after 6 seconds. The recorded configuration assigned 3 CPUs and 8 GB of RAM and used the image label lab-node:22. The build tail identifies Node.js v20.20.2; the image label does not establish the runtime version.
The failing build excerpt shows an attempt to invoke cargo metadata against /work/repo/Cargo.toml, followed by lifecycle errors. It does not establish why that invocation failed. A missing Rust installation is not a supported diagnosis from this excerpt.
The test summary listed 42 failed test files and no tests. Its stack excerpt names binding.js and native-test-setup.ts. This run supplies no executed-test correctness evidence, and the failed-file count must not be presented as 42 compiler defects. The timings also do not measure transformation performance.
The checkout contained 82,183 files, about 3,337,534 source lines, and occupied 397.7 MB. Our scan found monorepo workspaces and 16 CI workflow files. Although it found no tests directory, the test command discovered test files elsewhere. These counts describe repository layout, not test coverage or CI effectiveness.
Check the package route against your platform
The installation guide documents prebuilt packages through @swc/cli and @swc/core. It lists Apple Silicon and x64 Macs, several Linux architectures, Alpine Linux, Android aarch64, and Windows targets. For Alpine Linux, it specifically says to also install @swc/core-linux-musl. Check the environment that will load the native package against the documented targets.
The supplied README lists Node v10+ for usage and Node v20+ for development, with Rust 1.73 as the minimum supported Rust version for crates. Those are documented requirements, not compatibility results from our run. We did not reproduce the prebuilt-package route or establish the requirements of every package release.
For an application evaluation, start with the documented installation path and inspect representative output in the environments your project supports. For contribution work, first establish a working source build before relying on the repository's test suite.
Check React Compiler source maps separately
Issue 12602 reports missing mappings inside functions compiled with jsc.transform.reactCompiler. The reporter says the component's export function header retains a mapping while the compiled body does not. The report includes input, configuration, output, and mapping strings, and identifies @swc/core 1.16.20, with the same behavior also reported for 1.16.2 and 1.16.18.
This is an upstream report opened on October 23, 2026, not a defect reproduced in our October 10 run at commit b86e5c9. It does not establish that every SWC transformation has this problem.
If your team uses React Compiler and depends on source maps for breakpoints, stack traces, or coverage, inspect mappings for a representative component before enabling the transform. Successful code generation alone would not answer that debugging question.
Consider alternatives by the work you need done
Babel compiles JavaScript features into forms supported by older environments. If an existing Babel configuration already produces the required output, keeping it is a reasonable choice until an SWC migration has a demonstrated benefit. Our run provides no comparative output or performance measurements.
Esbuild documents built-in JavaScript, CSS, TypeScript, and JSX support, plus ESM, CommonJS, and CSS bundling. Evaluate it when bundling JavaScript and CSS is the immediate requirement. Those documented features provide a reason to consider it; this review does not establish that it will integrate successfully with a particular project.
The useful next step depends on your role: application teams can evaluate a documented package target and their own output fixtures, while contributors need to resolve the source-build workflow first.