Oxlint is the easiest part of Oxc to adopt
Oxc contains several layers of a JavaScript and TypeScript toolchain, all centered on Rust implementations. Application teams can run Oxlint and Oxfmt from npm. Tool authors can use the parser, transformer, minifier, resolver, and related crates or Node bindings. Rolldown uses Oxc for parsing, transformation, and minification, while the README names Nuxt, Preact, Shopify, and others as users of specific pieces.
That breadth can obscure the first decision. Most teams should evaluate one released CLI rather than replace an entire stack. Add Oxlint beside ESLint, compare diagnostics and ignored files, then decide which rules can move. Formatting deserves a separate review because Oxfmt and Oxlint have different release numbers and compatibility risks. Tool authors face a larger API commitment than CLI users.
The monorepo is 1.3 million lines across Rust and Node
Our checkout at commit 0e969e8 had 13,995 files, about 1,339,156 lines of source, and occupied 73.6 MB. It is a pnpm workspace monorepo with 32 CI workflow files. The scan found no Dockerfile and no directory literally named tests, although the repository plainly contains testing through workspace-specific layouts and commands.
Pnpm installed 745 packages in 31 seconds and consumed 688 MB. That dependency footprint belongs to source development across the workspace, not to the standalone binary a normal Oxlint user downloads through npm. The distinction matters for adoption: consuming one published tool is much easier than contributing to parser, semantic analysis, code generation, N-API bindings, and release packages together.
What happened when we ran it
Our build returned exit code 1 after 7 seconds. The tail shows @napi-rs/cli executing Cargo metadata while building the napi/minify workspace. Pnpm then reported ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL for oxc-minify@0.147.0 and stopped the recursive build. The visible log does not include the lower-level Cargo error, so it does not support a more specific diagnosis.
The test command failed after 5 seconds. Vitest summarized 2 failed files and no tests, then the same napi/minify package reported a recursive first failure for its test script. No assertion ran in the supplied tail. This is different from a suite with failing behavior: the workspace command failed before Vitest found executable tests in those files.
We ran these commands in a fresh unprivileged Node 22 Debian container with 3 CPUs and 8 GB of RAM. We did not benchmark Oxlint, compare output with ESLint, or run a released binary against an application. The failure says the monorepo was not self-contained in that environment; it does not measure the speed or correctness of the published CLI.
Plugin compatibility still needs a migration audit
Oxlint supports many familiar rules, but current issues show edges around JavaScript plugins. Issue 22117 says --print-config silently removes rules supplied through jsPlugins, even though those rules work during linting. That makes the printed configuration unreliable for one common migration check. A team should test effective behavior on files, not trust configuration output alone.
Issue 26115 reports that a disable comment with the wrong plugin prefix can silence a built-in rule sharing the same rule name. The reporter describes false negatives in Oxlint 1.80.0. This is a precise reason to compare suppression comments during migration, especially in a repository with many eslint-disable or plugin-specific directives. A faster linter that skips an intended diagnostic is not an acceptable trade.
A separate Oxlint 1.79.0 issue reports a React compiler invariant failure on computed-property destructuring. The report includes a short TypeScript reproduction and compares the official React compiler response. Teams enabling newer React rules should run them over the full codebase before making Oxlint required, because unusual syntax often lives outside the files chosen for a quick demo.
Releases move several products at different speeds
The latest GitHub release on August 24, 2026 combines Oxlint 1.80.0 with Oxfmt 0.65.0. Its notes include one new TypeScript lint suggestion, several rule and semantic fixes, and a formatter fix for decorators around suppressed statements. A combined release is convenient, but the different major versions show that the formatter and linter are at different maturity points.
GitHub listed 22,503 stars and 811 combined open issues and pull requests when fetched. The last push was August 26, and new issues plus patches were moving the same day. That queue reflects a broad, busy project rather than 811 confirmed bugs. It also means behavior can change quickly, so pin exact CLI versions in CI instead of running @latest there.
Trial one job before replacing the toolchain
Oxc is a credible foundation for JavaScript tooling, and the MIT license keeps commercial adoption simple. Its released binaries give application teams a low-cost way to try Oxlint without reproducing our failed 688 MB source workspace. Start with warnings only, capture diagnostic differences, and measure the repository's own CI time rather than borrowing project marketing.
Do not migrate linting and formatting together unless both comparisons pass. Keep ESLint for missing plugins, check every suppression namespace, compare --print-config with actual lint results, and review the Oxfmt diff as code. Our 7-second build failure is a contributor warning; the open compatibility reports are the stronger reason to stage adoption carefully.