Oxc: A Rust-Based JavaScript Toolchain That Replaces Multiple Build Steps
A collection of high-performance JavaScript tools. \* Oxidation is the chemical process that creates rust Who's using Oxc?
At a glance
- What is it?
- Oxc is a collection of Rust-powered JavaScript and TypeScript tools, including a parser, transformer, minifier, resolver, linter, and formatter. It powers Rolldown and is used by Nuxt, Preact, Shopify, and others, but its scope and maintenance demands need careful evaluation.
- Who is it for?
- Oxc is for teams that need a fast, unified JavaScript toolchain and are willing to adopt Rust-based infrastructure, especially those already using Vite or Rolldown. It is not for teams that require stable, mature formatter options or that cannot tolerate the risk of a fast-moving project with multiple components.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Oxc Actually Is
Oxc is not a single tool. It is a family of JavaScript and TypeScript tools written in Rust, distributed as separate crates and applications. The README lists six distinct components: a parser, a transformer, a minifier, a resolver, a linter (oxlint), and a formatter (oxfmt). Each can be used independently, but they share a common Rust core. The project is part of VoidZero's vision for a unified JavaScript toolchain, and it already powers Rolldown, the bundler that Vite is moving toward. The tagline 'Oxidation is the chemical process that creates rust' is a pun on the Rust language, and it signals the project's core bet: that rewriting JavaScript tooling in Rust can deliver performance gains that justify the complexity.
The Problem It Solves: Toolchain Fragmentation and Speed
JavaScript developers typically use separate tools for parsing, transforming, minifying, resolving modules, linting, and formatting. Each tool has its own configuration, its own parser, and its own performance characteristics. Oxc consolidates these into a single Rust codebase, which reduces duplication and allows optimizations that span multiple stages. For example, Rolldown uses Oxc for parsing, transformation, and minification, meaning the same parser handles the entire pipeline. The README also names Nuxt as a parser user, and lists Preact, Shopify, ByteDance, and Shopee as oxlint users. The target audience is clear: teams that build large JavaScript applications or tools and are tired of waiting for ESLint or Babel to finish. It is also for tool authors who want to embed a fast parser or resolver in their own project, as swc-node and knip do with oxc_resolver.
How the Components Fit Together
The architecture is modular. Each component lives in its own crate, but they share a common AST and parser infrastructure. The parser is the foundation: it parses JavaScript and TypeScript, and the transformer, minifier, and linter all consume that AST. The resolver handles module resolution, which is a separate concern but critical for bundlers and tools that need to find files. The linter and formatter are user-facing applications, while the parser, transformer, minifier, and resolver are libraries for building on top of. This separation means you can adopt just the resolver, as Nova and knip do, without pulling in the linter. The README does not provide a detailed data-flow diagram, but the component list and the examples of usage make the layering clear. The transformer handles TypeScript, JSX, and modern JavaScript, which suggests it is designed as a drop-in replacement for Babel in many scenarios.
Getting Started: Commands You Can Run Today
The README offers two immediate commands: `npx oxlint@latest` for linting and `npx oxfmt@latest` for formatting. These are the only commands given, and they are enough to try the tools on any codebase. For library usage, the README points to documentation pages for the parser, transformer, minifier, and resolver, but it does not list specific crate names or API calls. The resolver is documented at `https://docs.rs/oxc_resolver`, which is a concrete entry point for Rust developers. The project is MIT licensed, so you can use it in commercial projects without concern. The README also mentions a playground at `https://playground.oxc.rs/`, which is a practical way to test the parser and transformer without installing anything. Given the release cadence (crates_v0.147.0 and apps_v1.80.0 on the same day), the tools are under active development, and you should expect frequent updates.
Limitations and Failure Modes
The most obvious limitation is that Oxc is not a complete replacement for all JavaScript tooling. The README does not mention type checking, for example, and the transformer is not a full TypeScript compiler. If you need semantic type checking, you still need `tsc` or a language server. The formatter, oxfmt, is at version 0.65.0, which is below 1.0, so its output may change between releases. The linter, oxlint, is at version 1.80.0, which suggests stability, but its rule set may not cover every ESLint plugin you rely on. The README does not list any known limitations, but the version numbers and the project's youth (the last push was in 2026, and the project is still releasing crates with 0.x versions) indicate that breaking changes are likely. If you need a battle-tested formatter with a stable output, oxfmt is not yet that. If you need a linter with thousands of rules, oxlint may not match ESLint's ecosystem.
Alternatives and How They Differ
The main alternative is the traditional JavaScript-based toolchain: Babel for transformation, ESLint for linting, Prettier for formatting, and a bundler like webpack or Rollup. These tools are mature and have huge plugin ecosystems, but they are slower because they run in JavaScript. Another alternative is SWC, which is also a Rust-based JavaScript compiler. The README mentions swc-node, a project that uses oxc_resolver, which is interesting because swc-node itself is built on SWC. That shows that Oxc and SWC are not mutually exclusive; you can mix them. The key difference is that Oxc is a broader collection, including a resolver and a formatter, while SWC focuses on compilation and transformation. If you already use SWC, you might not need Oxc's transformer, but you might still want oxlint or oxfmt. The choice depends on whether you want to standardize on one Rust toolchain or pick the best component from each.
Maintenance and Upgrade Cost
Oxc is under active development, with releases for both crates and applications happening on the same day. The crates are still at 0.x versions, which means the API can change without a major version bump. The applications, oxlint and oxfmt, have separate versioning (1.x and 0.x respectively), which is a good sign for stability, but it also means you need to track two release lines. The README points to a troubleshooting page and a benchmarks page, but it does not provide a migration guide. For Rust developers, the cost is keeping your dependencies up to date with the latest crates. For JavaScript users who only use `npx oxlint@latest`, the cost is low: you get the latest version without a permanent dependency. The MIT license and the presence of third-party license notices suggest that the project is careful about legal compliance, which is a plus for enterprise adoption. However, the project's reliance on CI/CD sponsors and its position within VoidZero means that its long-term direction is tied to a commercial ecosystem, not just a community effort.
Editorial conclusion
Oxc is for teams that need a fast, unified JavaScript toolchain and are willing to adopt Rust-based infrastructure, especially those already using Vite or Rolldown. It is not for teams that require stable, mature formatter options or that cannot tolerate the risk of a fast-moving project with multiple components. Before adopting, verify that the specific tool you need (parser, transformer, minifier, resolver, linter, or formatter) is production-ready for your syntax and use case, and check the latest release notes for breaking changes.
Community notes