Oxc Linting: First Impressions from Our Techradar

At Divotion, we like to keep an eye on new tools and frameworks. Not because we want to chase every hype, but because it helps us make better decisions for our projects. To do that, we use a techradar, where we track tools that we want to assess, trial, or adopt.

In the next update of our Techradar, you will find Oxc in the trial lane. We placed it there because it does not yet support all ESLint rules, which means using it for a big project might not be wise. But with the recent introduction of TypeScript linting in Oxc, it made a huge step forward. That was reason enough for me to give it a try.

To see how it holds up in practice, I did a quick proof of concept on the codebase of our own Divotion website. In this article, I’ll share what that looked like, how smooth (or not) the setup was, and what my first impressions are.

Meet void(0)

The team behind Oxc is called void(0). Their mission is straightforward: make JavaScript and TypeScript tooling faster, safer, and easier to use. Instead of building yet another wrapper around existing tools, they are rewriting the foundations in Rust.

Oxc is more than only a linter. It is a complete suite that comes with a parser, a compiler, a bundler, and more. All parts share the same goal of creating modern tooling that can handle the scale of today’s projects without slowing developers down. Oxlint is one of the first tools from this suite that is ready for real use, and it is already turning heads because of the promise of speed and simplicity.

What I found in practice

For this proof of concept, I decided to swap out ESLint for Oxlint in the Divotion website. The project is not huge yet, which makes it a safe playground. We use a monorepo with a custom ESLint config package, so the first step was removing that package and setting up Oxlint in the root of the repo. Installation with pnpm was straightforward, and I added a small script with a base config.

Once it was running, I did a deep dive into the current state of the rules and plugins. The coverage surprised me. Oxlint already ships with a large set of rules, and I was able to opt into plugins I care about like React, import, and a11y. These plugins are not fully compatible yet, but they already provide a lot of useful checks. You can find the full list of supported rules here, which at the time of writing includes more than 500 rules. That already covers ESLint core and a good portion of the most popular plugins.

One thing I really liked is the option to run Oxlint alongside ESLint. You can lint with Oxlint first and then fall back to ESLint for anything that is missing. With the fixed config that Oxlint provides for ESLint you can automatically turn off duplicate rules, which makes the migration path much easier.

// eslint.config.js
import oxlint from 'eslint-plugin-oxlint';
export default [
  ...// other plugins
  ...oxlint.configs['flat/recommended'], // oxlint should be the last one
];

Another difference is how Oxlint approaches configuration. ESLint has always been a bit of a struggle for me, especially with TypeScript and the need for a Babel parser. With Oxlint, it was working almost instantly. That makes a big difference in developer experience. Instead of building up a large custom config, you rely more on the categories and plugins provided out of the box. You can still turn rules on or off using the same syntax as ESLint, but I like the idea of having categories as a base. It does take some time to figure out how to best use this for our project.

This was our full configuration:

{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "plugins": [
    "eslint",
    "typescript",
    "unicorn",
    "react",
    "oxc",
    "jsx-a11y",
    "nextjs"
  ],
  "rules": {
    "typescript/no-misused-spread": "off",
    "typescript/unbound-method": "off"
  }
}

Performance in practice

Performance was exactly as promised. In our CLI, we measured about a 3.5× speed-up compared to ESLint, and local development felt even faster. That alone makes it worth considering. On the other hand, since some rules are still missing, I would not fully replace ESLint just yet. Running it side by side feels like a good middle ground for now.

My takeaways and recommendations

Overall, I see Oxlint as a very strong contender to follow up ESLint once the ecosystem coverage is complete. Migrating was easier than expected, the speed gains are undeniable, and the configuration felt refreshingly simple. If you are curious, I recommend trying it out on your own project and seeing how far the rules have come. You might be surprised how ready it already feels. I’ll be keeping an eye on the project as it grows, and I’m curious to hear if others have tried Oxlint in their projects yet.