# Oxc: a Rust toolchain for JavaScript, from parser to linter

> Oxc is a collection of JavaScript and TypeScript tools written in Rust, spanning a parser, transformer, minifier, resolver, linter and formatter. The linter and formatter are the parts you can adopt today without touching your build pipeline.

**oxc-project/oxc** — A collection of high-performance JavaScript tools. \* Oxidation is the chemical process that creates rust Who's using Oxc?

- Repository: https://github.com/oxc-project/oxc
- Website: https://oxc.rs
- Stars: 22,901 · Forks: 1,323
- Language: Rust
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/oxc-project-oxc

## What Oxc is, and which part of it you actually install

Oxc is not one binary. The repository is a Cargo workspace whose members are apps/*, crates/*, napi/* and tasks/*, and the README splits the project into two layers. The first layer is what you run directly: Oxlint for linting and Oxfmt for formatting, both distributed through npm. The second layer is build tooling you embed: a parser, a transformer, a minifier and a module resolver. Those lower-level pieces are what Rolldown, Vite's bundler, consumes, and Rolldown also uses Oxc for transformation and minification.

That split matters for evaluation. If you are deciding whether to adopt Oxc, the honest question is which of those two layers you need. Most teams arriving from a search for an Oxc tutorial want the first layer, and the README answers that in one line each. The crates layer is a dependency for people writing their own tooling in Rust or through the napi bindings, and the README points at docs.rs for the resolver rather than at a CLI.

The naming is a pun. The README gives the pronunciation as /oʊ ɛks siː/ and footnotes that oxidation is the chemical process that creates rust. The project is part of VoidZero's stated plan for a unified JavaScript toolchain, which explains why the crates and the end-user binaries ship from the same repository on the same release cadence.

## How the pieces fit: parser, transformer, minifier, resolver

The README describes four build-tooling components and what each one takes in. The parser handles JavaScript and TypeScript. The transformer rewrites TypeScript, JSX and modern JavaScript. The minifier produces JavaScript for production builds. The resolver finds modules for JavaScript and TypeScript.

Adoption evidence sits in the README's list of consumers, and the pattern is worth reading carefully. Rolldown and Nuxt use Oxc for parsing. Rolldown additionally uses it for transformation and minification. Nova, swc-node and knip use oxc_resolver for module resolution. Preact, Shopify, ByteDance and Shopee use Oxlint for linting. So the parser has the widest adoption, the resolver has a distinct set of consumers, and the transformer and minifier are concentrated in Rolldown.

That concentration is a real signal about maturity by component rather than by project. A parser consumed by a bundler is exercised on every build of every project using that bundler. A minifier with one prominent consumer has a narrower surface of real-world input. The README does not publish a compatibility matrix for the transformer or minifier, so if you are considering them directly, the source to check is the usage pages the README links, not the top-level file.

The architecture document exists in the repository root as ARCHITECTURE.md, alongside MAINTENANCE.md and AGENTS.md. Those files are where the internal design is described; the README stays at the level of a component list.

## Installing Oxlint and running it on a real codebase

The README gives the linter as a single npx invocation with the latest tag. There is no separate installer step, and no global install is required. Run it from the root of the project you want to check:

```bash
npx oxlint@latest
```

Oxlint walks the codebase and reports diagnostics to stdout. Because the command is unversioned by default, pin the version in CI rather than relying on latest, otherwise the rule set can shift between runs.

For a configuration file, the repository itself is the example. Oxc's own root package.json defines its lint script as oxlint pointed at oxlintrc.json, with warnings promoted to failures and unused disable directives reported:

```json
{
  "scripts": {
    "lint": "oxlint -c oxlintrc.json --deny-warnings --report-unused-disable-directives"
  }
}
```

The same file shows the formatter wired the same way, against oxfmtrc.jsonc:

```json
{
  "scripts": {
    "fmt": "oxfmt -c oxfmtrc.jsonc"
  }
}
```

So the project's own convention is one config file per tool at the repository root, referenced with -c. Copy that shape rather than inventing flags. The devDependencies block in the same package.json lists oxlint and oxfmt with caret ranges, and also oxlint-tsgolint, which is a separate package the project depends on. The README does not explain what oxlint-tsgolint does, so treat it as something to investigate before adding it yourself.

For the formatter, the README gives the parallel one-liner:

```bash
npx oxfmt@latest
```

Run it on a branch first. A formatter that rewrites files will touch every file it disagrees with, and there is no documented dry-run flag in the README.

## The Rust side: building from source and the MSRV constraint

If you need the crates rather than the npm binaries, the workspace is the entry point. Cargo.toml declares members as apps/*, crates/*, napi/* and tasks/*, and excludes apps/shared, tasks/lint_rules and tasks/e2e. The workspace pins edition 2024 and rust-version 1.96.0.

The comment above that pin is unusually explicit about policy: MSRV Policy N-2 (12 weeks), described as a balance between core contributors using the latest rustc while waiting for dependents to catch up. Twelve weeks is a short support window. If your build environment lags Rust releases by more than a quarter, this workspace will move past you, and the maintainers have stated that is intentional rather than an oversight.

The justfile is the developer entry point. A just init target installs the Rust-side tools and runs pnpm install, and a just ready target runs the same commands as CI. The repository also ships rust-toolchain.toml, so the toolchain version is pinned for anyone building from a clone. The pnpm workspace covers the JavaScript side, with packageManager set to pnpm@12.3.2 in the root package.json.

Note the lint configuration in Cargo.toml. print_stdout and print_stderr are set to warn with a comment that they must be opt-in, and clone_on_ref_ptr is enabled with a comment about avoiding mindless clone calls. Those are opinions about how code inside this workspace should be written, and they tell you something about the review bar if you plan to contribute rather than consume.

## Where Oxc is the wrong choice

The clearest limitation is scope. The README presents Oxlint and Oxfmt as the two things you lint or format a codebase with, and presents the parser, transformer, minifier and resolver as tooling to build on. There is no documented standalone minifier CLI in the README, and no documented transformer CLI. If your need is a command-line minifier you can drop into a shell script, this repository does not advertise one, and the consumer list suggests the intended path is through Rolldown.

Second, the linter is a linter, not a replacement for every ESLint plugin in existence. The README does not claim plugin parity, and nothing in the repository describes a plugin compatibility layer. A project whose lint rules come from a long tail of community plugins should assume some of that coverage is missing until proven otherwise. The repository's own lint script uses --report-unused-disable-directives, which implies disable directives are a normal part of working with it.

Third, the formatter is new relative to the linter. The release naming separates them: apps_v1.80.0 covers oxlint v1.80.0 and oxfmt v0.65.0 in the same release. A 1.x linter and a 0.x formatter in one tag is a versioning statement, and a 0.x version is a boundary worth respecting if formatting stability matters to your diffs.

Finally, the Rust crates carry the twelve-week MSRV window described above. That is a maintenance cost, not a defect, but it is a cost that lands on anyone vendoring the crates.

## How Oxc differs from Biome

Biome is the obvious comparison for anyone evaluating a Rust-based JavaScript toolchain, and the difference is structural rather than a matter of speed. Biome is a single project that ships a linter and a formatter as its product. Oxc ships a linter and a formatter as one layer, and underneath them a parser, transformer, minifier and resolver intended to be embedded in other build tools.

That shows up in the consumer list. The README names Rolldown, Vite's bundler, as using Oxc for parsing, transformation and minification, and names Nova, swc-node and knip as using oxc_resolver. Those are integrations into build infrastructure, not end-user adoption of a lint command. Biome's comparable story is adoption of Biome itself.

Practically, if you want one tool that lints and formats and nothing else, the two are closer than the marketing suggests and the deciding factor should be rule coverage and formatter output stability, which the README does not let you compare. If you are building a bundler, a type checker or a language server and need a parser or resolver as a library, Oxc's crate layout and its use by Rolldown are the relevant facts, and Biome is not structured around that use case. The RELATED SEARCHES list pairs the two directly, which suggests people are making exactly this call.

## Licence, releases and what maintenance costs

Oxc is MIT licensed, stated in the README and in the LICENSE file at the repository root. The workspace Cargo.toml repeats license = "MIT" in the shared package metadata. MIT is permissive: it allows use in closed-source products and modification, with the usual requirement to preserve the copyright notice and licence text. That is a summary of the licence identifier, not legal advice, and it does not cover the third-party situation.

That third-party situation is the part to read before shipping. The README states that Oxc ports or copies code from other open source projects and points at THIRD-PARTY-LICENSE for the list. A file with that name at the repository root means the effective licence obligations of the distributed artifact are a union of MIT and whatever those entries say. If you are redistributing a build of Oxc, that file is the one to read, not the MIT badge.

The release cadence is visible from the tags: crates_v0.147.0 and apps_v1.80.0 both landed on 2026-08-24, with crates_v0.146.0 five days earlier on 2026-08-19. Crates and apps are versioned and released separately, so a crate version and an app version do not move together. The last push to the repository was on 2026-08-24. The repository is not archived.

Upgrade cost depends on which layer you consume. The npm binaries are pinned by your package.json, so upgrades are a version bump and a re-run of the linter or formatter. The crates are pinned by Cargo.lock but constrained by the twelve-week MSRV policy, so a dependency bump can force a toolchain bump. MAINTENANCE.md exists at the repository root and is the place to check for the maintainers' own statement on this, rather than inferring it from the release tags.

## Conclusion

Adopt Oxlint first if you want a fast lint pass that does not require rewriting your ESLint setup, and Oxfmt only after you accept a whole-repo reformat. Do not adopt Oxc expecting a drop-in replacement for every tool in your pipeline: the minifier and transformer are consumed by Rolldown and are not documented here as standalone products with their own CLI. Before committing, run npx oxlint@latest on a branch and diff the output against your existing linter, then check oxlintrc.json against the rule set your project already depends on.

## FAQ

### What does OXC mean?

It stands for the Oxidation Compiler, pronounced /oʊ ɛks siː/. The README footnotes the joke: oxidation is the chemical process that creates rust, and the tools are written in Rust.

### Is Oxc production ready?

The README lists Rolldown, Nuxt, Nova, swc-node, knip, Preact, Shopify, ByteDance and Shopee as users, across parsing, transformation, minification, resolution and linting. Readiness varies by component: the linter ships as 1.x while the formatter ships as 0.x in the same release tag, and the README does not publish a stability statement for the transformer or minifier.

### What are the benefits of using Oxlint?

The README presents Oxlint as the way to lint a codebase, runnable with npx oxlint@latest with no separate install step. It is used for linting by Preact, Shopify, ByteDance and Shopee according to the same list.

### What is an OXC?

Oxc is a collection of high-performance JavaScript and TypeScript tools written in Rust, covering a parser, transformer, minifier, resolver, linter and formatter. The README describes it as part of VoidZero's plan for a unified JavaScript toolchain, and it powers Rolldown, Vite's bundler.

## Sources

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

---

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