# SWC: a Rust compiler whose crates version independently, and native addons that unpack on first load

> SWC, the Speedy Web Compiler, is a TypeScript and JavaScript compiler written in Rust that is a library for both Rust and JavaScript users. Its crates are versioned independently with a promise that selecting the latest of each works together, its npm package ships a compressed native addon for a fixed set of targets, and the README itself carries no feature list and no benchmark numbers.

**swc-project/swc** — Rust-based platform for the Web. SWC (stands for Speedy Web Compiler) is a super-fast TypeScript / JavaScript compiler written in Rust.

- Repository: https://github.com/swc-project/swc
- Website: https://swc.rs
- Stars: 34,202 · Forks: 1,559
- Language: Rust
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/swc-project-swc

## Nightly tags carry the same version number as the release they precede

Look at the tag list before pinning anything. The three most recent entries are v1.16.13-nightly-20260930.1, v1.16.13 and v1.16.12-nightly-20260929.1, so a nightly is published under the version number of the release it is heading towards, with a date and a counter appended.

That naming is convenient for the maintainers and dangerous for a lockfile. v1.16.13-nightly-20260930.1 and v1.16.13 are different artifacts with the same base version, and the nightly one is a moving target that will be rebuilt. If a dependency range or a tag you copied resolves to the nightly line, your build changes without a version change in your manifest. Pin the release tag, not the nightly one, and treat anything with the nightly suffix as a preview of an unreleased version rather than as a fix for the version before it.

The version numbering itself is a sign of how often this ships. A patch landing on 2026-09-30 and another the day before is ordinary for a compiler that is also a set of independently versioned crates.

## The crates promise that selecting the latest of each will work together

The Rust side of SWC is a workspace of many crates, and the project makes a specific promise about them: if you select the latest version of each crate, it will work. That is the compatibility contract, and it is why there is no single swc version to pin. Rust users are pointed at the rustdoc for the swc crate, with the parser named as the entry point for most of them, and a crates.io link to swc_ecma_parser sits in the README header.

Keeping that promise across dozens of crates is what the update script is for:

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

It updates all dependencies to the latest version and then runs cargo build to confirm everything still compiles. Two things to know before you use it. It needs jq and cargo upgrade on your machine, so it is not a zero-setup command. And it pipes a downloaded script into bash, so it edits your Cargo.toml and lockfile in one pass with no review step; run it on a branch. The minimum supported Rust version for the crates is currently 1.73, which is the floor your toolchain has to clear before any of this applies.

## Node v10+ runs it, Node v20+ is what you need to build it

Two Node version lines appear in the README and they are not the same promise. Node v10 or newer is what usage requires, while Node v20 or newer is what development requires. The gap between them is roughly a decade of Node releases, and it tells you something about the shape of the project: the published package is expected to be consumed by far older toolchains than the one used to work on it.

For a consumer this is mostly good news, since an existing build pipeline is unlikely to be the reason you cannot adopt it. For a contributor it is a constraint, because the repository pins its own expectations: a rust-toolchain file at the root, a .node-version file beside it, pnpm as the declared package manager at version 10.33.3, and husky wired in as a prepare step. Nothing in the README says which of those files wins if they disagree, so take the repository's configuration rather than your own defaults when you set out to build from source.

JavaScript users are sent to the installation documentation on the website rather than to a snippet in the repository, which is consistent with a project that treats the repo as the source and the site as the manual.

## The npm package unpacks a verified native addon on first load

This is the part that decides whether the package works on your machine at all. The native npm packages use self-loading compressed addons on x64 and arm64 macOS, on Windows MSVC, and on Linux with either GNU or musl. On the first load the compressed addon is materialized as the verified original one, while the package names and the JavaScript APIs stay the same, so nothing in your code changes when it happens.

The target list is finite and the README is explicit that a boundary exists: the supported-target matrix and the environment variable SWC_NATIVE_BINDING_CACHE are documented in docs/native-addon-carriers.md. Read that before choosing SWC for a platform, because an unlisted target has no addon to load and the failure will surface at install or first run rather than as a graceful fallback.

SWC_NATIVE_BINDING_CACHE is worth understanding as well. It controls where the unpacked addon lives, which matters in environments where the install directory is read only, where a container rebuild throws the cache away, or where a warm cache is the difference between a fast and a slow CI job.

## The README has no feature list and no benchmark numbers, on purpose

Two sections of the README contain no content of their own. Features is a single line pointing at the comparison with Babel on the website, and Performance is a single line pointing at the benchmark results, also on the website. Nothing else in the file says what SWC can transform or how fast it is.

That is a deliberate division of labour: swc.rs is the manual, and the repository is the implementation. The practical consequence is that you cannot evaluate the project from the repository. The Babel migration page is the de facto feature reference, since a migration guide has to enumerate what changes and what does not, and the benchmark page is where any speed claim has to come from. If you are writing a decision document, those two pages are your evidence, and no number in this article should be read as one because the README contains none.

The header line, Make the web (development) faster, is a slogan rather than a measurement, which is worth keeping in mind when a comparison page quotes a figure back at you.

## One repository, two toolchains: pnpm workspaces and a cargo workspace

The JavaScript side is a pnpm workspace, not a single package. The root manifest is private, named @swc/workspace, declares pnpm@10.33.3 as its package manager, and lists workspaces covering .github/bot, the ecosystem CI, packages/*, the npm scripts under core, minifier, html and react-compiler, the bindings, and the wasm core binding. The scripts show how work is split:

```json
"changelog": "git cliff --output CHANGELOG.md; git cliff --output CHANGELOG-CORE.md --config cliff-core.toml",
"prepare": "husky install . && git config feature.manyFiles true && node ./crates/swc_ecma_preset_env/scripts/copy-data.js",
"build": "cd ./packages/core && pnpm build",
"test": "cd ./packages/core && pnpm test",
"test:minifier": "cd ./packages/minifier && pnpm test"
```

Note that Babel is a devDependency here, alongside @swc/core and @swc/helpers as workspace references, which is how the comparison the README defers to the website gets tested. On the Rust side, Cargo.toml makes a workspace of xtask, bindings/*, crates/* and three tools, including swc-releaser and swc-native-addon-pack. Add deny.toml, clippy.toml, .rustfmt.toml, .taplo.toml, cspell.json, sgconfig.yml and a .changeset directory to that and the picture is a monorepo with two build systems, two formatters and a release tool of its own.

## Volunteer maintained, Apache-2.0 primarily, with a MAINTENANCE.md of its own

The project describes itself as community-driven and maintained by a group of volunteers, with a Discord server and GitHub discussions offered as the places to ask, and an OpenCollective page for funding. The last push to the repository was 2026-09-25 and v1.16.13 was published on 2026-09-30, so the commits and the tags are close together right now.

Two files in the root are worth knowing about before you depend on any of this. MAINTENANCE.md exists as a separate document, which usually means the rules about what gets merged and when are written down somewhere other than the README. And SECURITY.md exists next to it, so a vulnerability report has a defined destination.

The licensing sentence is the one to read carefully. SWC is primarily distributed under the terms of the Apache License, Version 2.0, with the LICENSE file holding the detail. That word primarily is doing work: it signals that some parts ship under other terms, and Cargo.toml records the same Apache-2.0 value for the workspace. If you vendor SWC into a product, read LICENSE rather than repeating this sentence back to a legal reviewer.

## Conclusion

Use SWC when you want the Rust parser as a library, or a Node toolchain whose native addon covers one of the listed targets, and you are willing to read swc.rs rather than the repository to learn what it does. Skip it if your target platform is missing from the addon carriers list, or if you need a feature set documented only in the Babel migration guide. Before adopting: pin an exact version rather than a nightly tag such as v1.16.13-nightly-20260930.1, keep the MSRV of 1.73 in mind for the Rust side, confirm your Node version is v10 or newer to consume the package and v20 or newer to build it, and read LICENSE rather than trusting the phrase primarily distributed, because the README qualifies its own Apache-2.0 terms.

## FAQ

### What does SWC stand for?

SWC stands for Speedy Web Compiler. It is a TypeScript and JavaScript compiler written in Rust, and the project describes it as a library for Rust and JavaScript at the same time.

### What is SWC in TypeScript?

It is the compiler that turns TypeScript and JavaScript, and it is written in Rust. Rust users are pointed at the swc rustdoc, with the parser crate named as the entry point for most of them, while JavaScript users are sent to the installation documentation on the website.

### What are the benefits of using SWC?

The README does not claim any. Its Features section is one line pointing at the comparison with Babel, and its Performance section is one line pointing at the benchmark results, both on the website. The concrete facts it does state are the Rust implementation, an MSRV of 1.73 for the crates, and a promise that selecting the latest version of each crate will work together.

### What is the full form of SWC, and where does the name show up?

Speedy Web Compiler. The abbreviation is what you type in practice: the npm package is @swc/core, the Rust entry point for most users is the parser crate swc_ecma_parser, and the script that updates every crate is scripts/update-all-swc-crates.sh.

## Sources

- [Official documentation](https://swc.rs)
- [Official README](https://github.com/swc-project/swc#readme)
- [Project repository](https://github.com/swc-project/swc)
- [Release notes](https://github.com/swc-project/swc/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/swc-project-swc