Oxc: Rust-Based JavaScript and TypeScript Toolchain

What Oxc is

Oxc, the Oxidation Compiler, is a collection of high-performance tools for JavaScript and TypeScript written in Rust. It covers the whole toolchain: parsing, module resolution, linting, formatting, transforms and minification. The project describes itself as part of VoidZero's vision for a unified JavaScript toolchain, and it powers Rolldown, the bundler used by Vite 8. (The footnote explains the name: oxidation is the chemical process that creates rust.)

Oxc ships both end-user tools and reusable compiler building blocks. Most developers meet it through Oxlint, a linter aiming at ESLint compatibility, and Oxfmt, a formatter aiming at Prettier-compatible output. Tool authors use the parser, transformer, minifier and resolver as Rust crates or npm packages. The website lists three audiences: app and library developers who want a fast lint and format loop, platform teams who want a compiler-grade foundation, and authors of JavaScript tooling. It is MIT-licensed.

How it works

The core idea is one toolchain on shared building blocks. The linter, formatter, parser, transformer, minifier and resolver are built on common components, which the project says reduces duplicated work and makes behaviour more consistent across tools. Each piece can be used on its own or together.

The stated philosophy has four parts: performance is a feature (regressions are treated as bugs), one toolchain with shared building blocks, correctness with clear boundaries (differences from other tools should be documented), and practical defaults. Oxlint adds two notable capabilities on top of the shared stack. For type-aware rules it uses tsgo, the native Go port of the TypeScript compiler (TypeScript 7), rather than its own type inference, so rules like detecting floating promises follow TypeScript's own semantics. And it supports multi-file analysis: when enabled, it builds a project-wide module graph shared across rules, which the docs say avoids the performance cliff of rules like import/no-cycle in ESLint.

Key features

• Oxlint: a large ruleset (the docs compute the exact count from the rule list) covering ESLint core, TypeScript (including type-aware rules), and plugins such as React, Jest, Vitest, Import, Unicorn and jsx-a11y, with correctness-focused defaults.
• ESLint-compatible JS plugins: custom plugins compatible with the ESLint plugin ecosystem.
• Migration tooling: @oxlint/migrate converts an existing ESLint config, and eslint-plugin-oxlint disables overlapping rules when running both.
• Oxfmt: Prettier-compatible formatting for JavaScript, TypeScript, JSX, JSON, YAML, TOML, HTML, CSS, SCSS, Less, Markdown, MDX, GraphQL, Vue, Svelte, Angular and more.
• Batteries included formatting: built-in import sorting, Tailwind CSS class sorting, package.json field sorting and embedded formatting for CSS-in-JS and GraphQL, which normally need Prettier plugins.
• Parser producing an AST for tooling, plus a transformer for TypeScript, JSX and modern JavaScript, and a minifier.
• Resolver: oxc_resolver for JavaScript and TypeScript module resolution, used by Nova, swc-node and knip according to the README.
• TypeScript runner: runs TypeScript and JSX directly in Node.js.
• Machine-readable diagnostics: Oxlint output includes precise spans, context and documentation links, designed for both humans and AI tools applying fixes.

Getting started

To try the linter or formatter on a codebase without installing anything, the README gives:

npx oxlint@latest

npx oxfmt@latest

For a project, the docs recommend installing Oxlint as a dev dependency:

pnpm add -D oxlint

and adding scripts to package.json:

{
  "scripts": {
    "lint": "oxlint",
    "lint:fix": "oxlint --fix"
  }
}

Oxfmt follows the same pattern:

pnpm add -D oxfmt

{
  "scripts": {
    "fmt": "oxfmt",
    "fmt:check": "oxfmt --check"
  }
}

pnpm run fmt:check

The docs then cover configuration, editor setup and CI for each tool, and a dedicated guide for migrating from ESLint. They describe two adoption paths. For most projects the recommendation is to replace ESLint outright and use @oxlint/migrate to carry the existing configuration across. For especially large or complex repositories, the recommendation is to migrate incrementally: run Oxlint first, then run ESLint with the overlapping rules turned off through eslint-plugin-oxlint, which keeps CI fast while rules move over one group at a time.

Use cases

• Speeding up CI linting in large repositories and monorepos, either replacing ESLint outright or running Oxlint first and ESLint with overlapping rules disabled during an incremental migration.
• Replacing Prettier plus plugins with one formatter that already sorts imports and Tailwind classes.
• Type-aware checks such as floating-promise detection, using TypeScript's own type system through tsgo.
• Building JavaScript tooling: bundlers, frameworks and analysis tools using the parser, transformer or resolver. The README says Rolldown and Nuxt use Oxc for parsing and Rolldown also for transformation and minification.
• Linting framework files: .vue, .svelte and .astro files, where Oxlint lints only the <script> blocks.

How it compares

The project's own comparisons are with ESLint, Prettier, Biome, swc, Babel and webpack's enhanced-resolve, and all speed figures are the project's benchmark claims, each linked to a public benchmark repository. The benchmarks page claims Oxlint is 50x to 100x faster than ESLint depending on CPU cores, that the parser is at least 3x faster than swc and 5x faster than Biome (noting this is not apples-to-apples because Biome produces a CST), that the transformer is 4x faster than swc and 40x faster than Babel, and that oxc-resolver is 30x faster than enhanced-resolve. For the formatter, the Oxfmt page says approximately 30x faster than Prettier and 2x faster than Biome, while the benchmarks page gives 35x and 3x; check the benchmark repository for current numbers. On type-aware linting, the docs contrast Oxlint's use of the TypeScript compiler with Biome's own type inference. The docs also say to stay on ESLint or Prettier only if you depend on plugin behaviour Oxc does not yet cover, and point to Vite+ for a unified toolchain that bundles Oxlint and Oxfmt.

Things to know before adopting

• Versioning differs per tool: releases are tagged separately, for example oxlint_v1.89.0, oxfmt_v0.74.0 and crates_v0.155.0 in October 2026, so Oxlint is past 1.0 while Oxfmt and the crates are still 0.x.
• Prettier divergences: Oxfmt uses Prettier's output as its baseline and is tested against Prettier's test suite, but deliberately diverges where it considers Prettier's behaviour a bug, and some defaults and CLI options differ. The docs keep a list of known divergences and unsupported features.
• Plugin edge cases: ESLint plugins with unusual behaviour may not be fully supported; the docs suggest incremental migration for large, complex repositories.
• Framework files: Oxlint lints only script blocks in Vue, Svelte and Astro files, not templates.
• Third-party code: Oxc ports or copies code from other open-source projects, with their licences listed in THIRD-PARTY-LICENSE.
• Licence: MIT.

Project activity

As of October 2026 the repository has about 23,200 stars and roughly 1,400 forks. It was created in February 2023, is written in Rust, is licensed under MIT, and ships frequent releases, with new Oxlint, Oxfmt and crate versions published weekly in October 2026. The README lists Preact, Shopify, ByteDance and Shopee among Oxlint users. Documentation, benchmarks and a playground are at oxc.rs, and the source is at github.com/oxc-project/oxc.