Oxlint Integration Plan

[antfu]

I have received several requests asking to support oxlint in this config. Creating this issue as the epic issue to track the progress and have a single place for discussion.

The most important thing for me:

Important

This config is trying to provide an all-in-one, out-of-the-box, highly configurable linting experience.

Under that definition, it doesn't have to be ESLint or even bound to any tools. So, regarding oxlint support, the answer is yes, I am happy to support it if it benefits the users while maintaining that goal.

---

So if we think about the current state of oxlint, the pros and cons we will have:

Pros

• Speed (usually more interesting for giant projects)

Cons

• Losing a lot of custom plugins/rules
• Custom files linting, Vue, YAML, Markdown, CSS, etc.
• Static Config (current in JSON), which is not easily shareable and configurable.

---

Considering losing features is definitely not acceptable to trade speed, at the status quo, the only option would be running ESLint in conjunction with oxlint. oxlint for common rules with great speed and ESLint to cover custom plugins/rules. But then we will have other problems:

• A separate CLI to run
• A separate config (in JSON for now) to maintain
• Embedded languages are tricky to configure (TS in Vue, JS in Markdown, CSS in HTML, etc.)
• oxlint currently has no plan to port ESLint Stylistic
• Considering we might still need to run ESLint for most of the files, the speed improvement would also be questionable.

In that case, I feel it's not ready for us to adapt to it, as it would complicate things significantly, not only on our side but also on the user side for configuring and setting up both tools (a.k.a. we can't absorb many of these complexities from users).

---

Note

In short: ⏳ oxlint is NOT READY, and we are still waiting.

---

In the future, I see there are two approaches that we might be able to move forward:

A. oxlint in ESLint

If oxlint could provide a fine-grained, programmatic JS API, we might have oxlint running as ESLint rules to speed up rules that oxlint supports. In this way, we could still use eslint CLI and have this config as the single source of truth.

B. oxlint to replace ESLint

I believe it's one of the goals of oxlint to be the drop-in replacement of ESLint. They recently announced the JS Plugin API supporting a subset of the ESLint plugin API (https://oxc.rs/blog/2025-10-09-oxlint-js-plugins.html), which I see is pretty promising. But in order to be a drop-in replacement, there are still things pending for us:

• Flat config
• More JS Plugin compatibility (and pass through Flat Config)

If that day happens, in the most ideal case, you should be able to directly use this config without you or me doing anything (drop-in). For a more realistic thinking, it would take much time and better do it progressively, so I will work with the oxlint team to help test out and do the API compatibility adaptation, etc.

---

So, please be patient and wait, subscribe to this thread if you want to get notified or so. Or maybe you can re-evaluate if you need the additional things from my config (that oxlint does not yet support), or you might want to switch fully to oxlint by moving away from this config, or consider other plans.

Let's me know if you have any other concerns!

---

Ref

• add oxlint #535
• Add Oxlint implementation guide and CLI option #631
• Support oxc #761
• 目前新建的vue项目可选oxlint 了，希望大佬可以官方支持一下 oxlint + eslint + @antfu/eslint-config #755

[SiriusCrain]

Btw you can check jsPlugin option within oxlint, it will not give you a native oxlint speed for now, but built-in rules will be much faster

[antfu]

Btw you can check jsPlugin option within oxlint, it will not give you a native oxlint speed for now, but built-in rules will be much faster

I already mentioned it. It's not only able to use the plugins in JS (which is a great first step tho!) but also the config for fine-grained configuration and config factory. We don't want to leak the implementation details to users or ask users to do any additional setup to use oxlint.

[TheAlexLichter]

Appreciate the openness regarding moving over and not being tied to a specific linter, while also outlining current shortcomings.
I'm confident we will get there over time 👏

[SiriusCrain]

Btw you can check jsPlugin option within oxlint, it will not give you a native oxlint speed for now, but built-in rules will be much faster

I already mentioned it. It's not only able to use the plugins in JS (which is a great first step tho!) but also the config for fine-grained configuration and config factory. We don't want to leak the implementation details to users or ask users to do any additional setup to use oxlint.

Oh, I missed it, sorry for confusion)
FYI I used it already, and speed drastically degrade over it for now, like use of built-in rules pass within 500-700ms, with jsPlugin it takes up to 8 seconds on the same codebase

[TheAlexLichter]

Oh, I missed it, sorry for confusion) FYI I used it already, and speed drastically degrade over it for now, like use of built-in rules pass within 500-700ms, with jsPlugin it takes up to 8 seconds on the same codebase

@SiriusCrain That is somewhat expected (see the perf part of the announcement post) and will be focused on in future releases. It would be super helpful to share which rules you are using and how many files you are checking though!

[SiriusCrain]

Oh, I missed it, sorry for confusion) FYI I used it already, and speed drastically degrade over it for now, like use of built-in rules pass within 500-700ms, with jsPlugin it takes up to 8 seconds on the same codebase

@SiriusCrain That is somewhat expected (see the perf part of the announcement post) and will be focused on in future releases. It would be super helpful to share which rules you are using and how many files you are checking though!

Sure, I installed eslint-plugin-array-func, use totally 148 rules, 1570+ files