SWC: a Rust JavaScript and TypeScript compiler you can use from Node or from Rust

What SWC replaces, and who ends up using it

SWC is a TypeScript and JavaScript compiler. It takes source files and produces JavaScript, the same job Babel does in most front-end toolchains. The README states the project is "a library for Rust and JavaScript at the same time," which is the part that separates it from a plain CLI tool. Two audiences follow from that. The first is a JavaScript or TypeScript developer who wants compilation to happen faster than a JavaScript-implemented compiler manages, usually inside a bundler or a test runner. The second is a Rust developer who needs to parse, transform or print ECMAScript and does not want to write a parser. The repository is organised around that split: crates/ holds the Rust crates, bindings/ holds the native and WebAssembly bindings, and packages/ holds the npm packages. For most people reading this, the entry point is the @swc/core npm package, not the Rust crates. The README points JavaScript users at the installation docs on swc.rs and Rust users at rustdoc.swc.rs, with swc_ecma_parser named as the usual starting crate.

How the Rust crates and the JavaScript binding fit together

The architecture is a Rust workspace. The root Cargo.toml declares members across xtask, bindings/*, crates/* and the tools directories, and it pins shared dependency versions in a [workspace.dependencies] table, so a crate in the repo does not choose its own version of, say, browserslist-rs. On top of that sit the bindings, and on top of the bindings sit the npm packages. The README describes the compatibility promise for Rust users in one line: if you select the latest version of each crate, it will work. That is a useful guarantee, but read it as a constraint too. It means the crates are expected to move together rather than to be mixed at arbitrary versions. The repository ships scripts/update-all-swc-crates.sh for exactly this situation. The README gives the command that runs it and says it updates all dependencies to the latest version and runs cargo build to check that everything still compiles, and that it needs jq and cargo upgrade to run. The workspace also carries ARCHITECTURE.md, which CONTRIBUTING.md points to for the internal layout.

Installing @swc/core and compiling your first TypeScript file

The README sends JavaScript users to the installation page at swc.rs/docs/installation, and the npm package is @swc/core. Node v10 or later is listed as the supported version for usage; Node v20 or later is required only if you are developing SWC itself. The README does not print a usage snippet for the JavaScript API, so the only executable lines reproduced here are the ones the repository actually contains. The first is the crate update script, which the README gives verbatim. It fetches the script from the main branch and pipes it into bash, and the README notes the jq and cargo upgrade commands must be available first.

curl https://raw.githubusercontent.com/swc-project/swc/main/scripts/update-all-swc-crates.sh | bash -s

The second is the project's own build entry point, taken from the root package.json. It changes into ./packages/core and runs the build script there, which is how the SWC repository builds its own packages rather than how you would build an application.

cd ./packages/core && pnpm build

Two more scripts from the same file are worth knowing because they show the expected workflow: build:dev and build:ts are the development variants, and test:core runs the core package tests. Those are workspace scripts, so they assume the pnpm workspace is already installed. If you only want to compile your own project, the README's answer is the installation page on swc.rs, which is where the JavaScript API usage is documented.

The Rust side, and the MSRV you have to plan around

Rust users add the crates rather than the npm package, and the README names swc_ecma_parser as the entry point for most of them. The minimum supported Rust version for the crates is stated as 1.73. That number is the first thing to check against your toolchain, because it is a floor, not a target: a project pinned to an older compiler cannot consume the crates at all, and the README does not offer a backported branch. The update script is the second thing to look at. Because the compatibility promise is that the latest version of every crate works together, upgrading one SWC crate in isolation is the scenario the project is least likely to support. The script exists to move the whole set at once and then prove it builds. In a workspace with several SWC crates, that means a version bump is a coordinated change, and you should expect the diff to touch every SWC dependency line rather than one. The README notes the script needs jq and cargo upgrade installed before it will run.

Where SWC is the wrong choice

The README's own feature pointer is a comparison with Babel, hosted on the website, and that is the honest place to start when judging fit. The gap is not speed, which the project claims as its reason to exist; it is the surrounding surface. Babel's plugin ecosystem and its accumulated documentation for unusual transforms are the reason many teams stay on it, and nothing in the README claims SWC matches that breadth. If your build depends on a specific Babel plugin that has no SWC equivalent, migration is not a configuration change. The second limitation is the versioning model. The promise that the latest of each crate works together is a promise about the latest, and it implies that older combinations are not the supported path. A team that needs to freeze a dependency set for a long release cycle is fighting that model. Third, the README does not document rollback or downgrade steps, so if an upgrade breaks your build, the recovery path is your own version control rather than a documented procedure. None of these are defects in the compiler itself. They are properties of how the project is packaged and maintained, and they matter as much as compile time when you are deciding.

SWC against Babel, and the difference that actually matters

Babel is the natural comparison, and the project makes it explicitly by linking a migration guide. The difference in approach is where the work happens. Babel is a JavaScript program: its transforms are plugins written in JavaScript, loaded at build time, and a team can read and patch them in the same language as the application. SWC is a Rust program with a JavaScript binding, so the transform core is compiled, and the JavaScript side calls into it through @swc/core. That is the trade. You get a compiler whose hot path is not interpreted, and in exchange the extension point is not a JavaScript file you can edit in place. For a team with no custom transforms, the trade is close to free. For a team with a folder of in-house Babel plugins, it is the whole migration. The repository's devDependencies list includes @babel/core, @babel/preset-env and several Babel presets, which tells you the project tests itself against Babel's compatibility data rather than only against its own output. That is a point in SWC's favour for correctness, and it does not change the plugin story.

Maintenance, releases and what the Apache-2.0 licence means for you

The repository is not archived, and the last push was on 2026-08-19. The release list shows a stable v1.16.1 alongside nightly builds tagged with a date, for example v1.16.1-nightly-20260819.1. That pattern matters for upgrade cost: if you depend on a nightly-only fix, you are tracking a build that is replaced daily, and the stable line is the one with a version number you can pin. The README describes SWC as community-driven and maintained by a group of volunteers, with Discord and GitHub discussions named as the places to ask for guidance. Volunteer maintenance is not a criticism, but it does mean you should not expect a commercial support contract behind the version numbers. On licensing, the README states SWC is primarily distributed under the Apache License, Version 2.0, and the workspace Cargo.toml sets license = "Apache-2.0" for the workspace package. The word primarily is doing work there: it leaves room for components under other terms, so if you vendor or redistribute SWC, read LICENSE and the individual crate manifests rather than relying on the README line. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt SWC when you want a TypeScript or JavaScript compiler that runs both inside a Node build pipeline and inside a Rust program, and when you are willing to track crate versions rather than pin one. Do not adopt it if you need a compiler whose plugin surface and documentation are as deep as Babel's, or if you need a stable MSRV above the one the project names. Before committing, check the MSRV note in the README against your toolchain, read ARCHITECTURE.md for how the crates fit together, and run the update-all-swc-crates script in a branch so you can see what a version bump touches.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes