Oxc: the Rust toolchain under Rolldown, plus oxlint and oxfmt

Rolldown parses, transforms and minifies on top of Oxc

The adoption list in the README is not a logo wall, and the split between crates is informative. Rolldown and Nuxt use Oxc for parsing. Rolldown also uses Oxc for transformation and minification. Rolldown is Vite's bundler. Three other tools take a much narrower slice: Nova, swc-node and knip use oxc_resolver for module resolution alone, and that crate carries its own documentation on docs.rs. Read that as a signal about which pieces are considered settled enough to consume on their own. Linting is the widest surface. Preact, Shopify, ByteDance and Shopee are named as oxlint users, so the linter is the component most often already running on hardware you control. One limit on all of these claims: no consumer is listed with a version, a configuration or a use case, so nothing in the README tells you whether a given project sits on the resolver alone or on the full pipeline.

Two npx commands and the config files they point at

The daily entry points are one line each. For linting, npx oxlint@latest. For formatting, npx oxfmt@latest. Both tools are also wired into this repository's own package.json, which shows the flags the project actually leans on. The formatter is pointed at a checked-in config:

oxfmt -c oxfmtrc.jsonc

The linter runs with warnings promoted to failures and reports disable directives that no longer suppress anything:

oxlint -c oxlintrc.json --deny-warnings --report-unused-disable-directives

Both config files live at the repository root next to .editorconfig, .rustfmt.toml, .clippy.toml and .typos.toml, so the Rust and JavaScript halves of the project keep their formatting rules in one directory. Two things worth noticing. Nothing in the README states what defaults either tool applies when no config file is present, so the behaviour of a bare npx run is not something you can read a spec for here. And the devDependencies pin oxlint at ^1.66.0 and oxfmt at ^0.75.0, while the most recent oxlint release recorded is v1.90.0. A caret range admits both.

oxc_resolver is the piece other tools import on its own

oxc_resolver is the one Oxc crate the README names as a standalone dependency in other projects: Nova, swc-node and knip each take it for module resolution, and its API documentation is linked on docs.rs. That placement tells you where to read the code before you depend on it. The tree also carries two build systems with different coverage. Cargo.toml lists workspace members as apps/*, crates/*, napi/* and tasks/*, and excludes apps/shared, tasks/lint_rules and tasks/e2e. The pnpm build scripts cover a different set, filtering on ./napi/*, ./apps/* and ./packages/* with workspace concurrency pinned to one so the native builds serialise.

So packages/ holds JavaScript work the Cargo workspace never builds, and tasks/ holds Rust automation pnpm never builds. The setup recipe only installs tooling:

cargo binstall watchexec-cli cargo-insta typos-cli [email protected] -y

print_stdout is opt-in and the rustc floor tracks recent releases

The Rust side is stricter than most libraries, and that has consequences for anyone who forks or vendors it. The workspace sets edition 2024 and declares a minimum supported Rust version with the policy written next to it, MSRV Policy N-2 over twelve weeks, described as balancing contributors using the latest rustc against waiting for dependents to catch up:

edition = "2024"
rust-version = "1.97.0"

A crate that pins an older toolchain cannot build this at all, and because the floor moves on a twelve week cadence, that constraint is not permanent. The lint set explains a lot of the code's shape. print_stdout and print_stderr are warned on with the comment that they must be opt-in, so library code cannot quietly print to a terminal. dbg_macro, todo and unimplemented are warned on too, which keeps unfinished paths visible in review. clone_on_ref_ptr is warned on, with a comment saying the rule exists to remove confusion around clone and avoid heap allocating by accident. unsafe_op_in_unsafe_fn and unused_unsafe are warned on, so the unsafe surface is meant to be audited rather than accumulated. If you take a copy of these crates, you inherit that lint policy and a rustc floor that follows recent releases instead of a long support window.

The justfile ready recipe runs eleven commands and ends on git status

The contributor path is a justfile, and the release gate is a single recipe called ready, aliased to r. It runs eleven commands in order:

git diff --exit-code --quiet
pnpm install
typos
cargo lintgen
just fmt
just check
just test
just lint
just doc
just ast
git status

The last step is git status, which means the recipe is meant to be read as well as run. If formatting or codegen rewrote a file, that diff is the output. Two recipes raise problems to failures rather than merely reporting them. Linting sets CARGO_BUILD_WARNINGS to deny before calling cargo lint, and documentation builds with RUSTDOCFLAGS set to -D warnings together with --document-private-items, so rustdoc warnings on private items fail the build. Formatting opens with cargo shear --fix --check-test-targets to remove unused dependencies, then runs cargo fmt and node --run fmt. Linting has a separate Windows recipe because that build variable has to be set in PowerShell, and the file sets its Windows shell to powershell.exe. Contributors need cargo binstall plus pnpm at the version pinned in package.json, which is pnpm 12.7.0, and CI runs on macOS and Linux runners provided by namespace.so. The practical consequence is blunt: one rustc warning or one rustdoc warning fails the run.

Five crates have a WASI build path and the resolver is not one of them

Not everything in the tree has a route to a non-Node runtime. package.json defines one WebAssembly build script and one WASI build script, and the WASI script names its crates outright:

pnpm --workspace-concurrency=1 --filter oxc-parser --filter oxc-minify --filter oxc-transform --filter oxc-transform-react --filter oxc-transform-relay build-wasip1-dev

Five crates, all parsing, transforming or minifying. The resolver has no WASI script, and neither do oxlint or oxfmt. If your goal is module resolution or linting from a browser or another WASI host, no script here covers it, and the README names no consumer outside Node, so that route means building it yourself. The Node side is a separate mechanism again: napi/ holds Node-API bindings, and the generic wasm script filters all of napi/ without naming crates, so each package there must declare its own target. One more catch for a fresh clone. The submodules recipe clones test data and then refreshes transformer fixtures through just update-transformer-fixtures.

The four library crates get one line each and a link

For Parser, Transformer, Minifier and Resolver, the README is a directory rather than a specification. Each gets a single sentence and a link to oxc.rs. There is no list of supported syntax, no error format for parse failures, no statement of which proposals are implemented, and no comparison against another parser or transformer. The files that would fill those gaps sit at the repository root instead, ARCHITECTURE.md and MAINTENANCE.md and CHANGELOG.md and CONTRIBUTING.md, alongside a deny.toml for dependency auditing and the justfile that ties the checks together. Versioning is the sharper warning. The latest releases are oxlint v1.90.0 and oxfmt v0.75.0, both on 27 October 2026, and the crates line at v0.157.0 on 2 November 2026. oxlint sits on 1.x, while oxfmt and the library crates remain on 0.x, which under SemVer rules carries no compatibility guarantee at all. So a team pinning the crates as direct dependencies should expect to track breaking changes on a schedule set by maintainers, and should not read the fact that Rolldown, Nuxt, Preact, Shopify, ByteDance and Shopee use parts of Oxc as evidence that the crate APIs are stable for outside callers.

Editorial conclusion

oxlint and oxfmt are the easy part to try: each is one npx command, and the Oxc repository formats and lints itself with both, so you can judge them on your own code before committing. The library crates are a different decision. Oxc is already load bearing inside Rolldown and Nuxt, and the resolver inside swc-node, knip and Nova, but the crates line is still on a 0.x number, the declared rustc floor is 1.97.0 and only five crates have a WASI build path, so check your Rust version, your runtime targets and your tolerance for breaking changes before you design around them.

Frequently asked questions

Official sources

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