oxlint JS plugins blog post #542
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This stack of pull requests is managed by Graphite. Learn more about stacking. |
overlookmotel
commented
Oct 9, 2025
Boshen
approved these changes
Oct 9, 2025
Base automatically changed from
10-08-docs_linter_add_js_plugins_documentation
to
main
October 9, 2025 07:34
overlookmotel
force-pushed
the
10-09-oxlint_js_plugins_blog_post
branch
from
91c25a7 to
ae91723
Compare
✅ Deploy Preview for oxc-project ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
overlookmotel
force-pushed
the
10-09-oxlint_js_plugins_blog_post
branch
from
ae91723 to
b860331
Compare
overlookmotel
force-pushed
the
10-09-oxlint_js_plugins_blog_post
branch
from
b860331 to
346ab85
Compare
camc314
reviewed
Oct 9, 2025
| Run Oxlint: | ||
|
|
||
| ```sh | ||
| pnpm oxlint |
There was a problem hiding this comment.
should this be pnpx? or should it be clear that oxlint is a script in the package.json?
camc314
reviewed
Oct 9, 2025
| to inform design for Oxlint support for custom JS plugins. Today, we are pleased to announce the result of many months | ||
| of research, prototyping, and finally building: | ||
|
|
||
| **Oxlint supports plugins written in JS!** |
There was a problem hiding this comment.
should we also add the eslint compat here in the headline?
| - Performance is good, but it's going to get _way_ better - we have many optimizations in the pipeline. | ||
|
|
||
| The most commonly-used APIs for code-checking rules [are implemented](#features), so many existing ESLint rules will already work. | ||
| But token-related APIs are absent, so stylistic (formatting) rules will not. |
There was a problem hiding this comment.
mention antfu config here briefly & plans?
we're going to fix these in a follow up so the blog post is there and published in time for the talk |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Draft blog post announcing Oxlint JS plugins.
It's not quite as polished as I'd like it to be, but we need to get it out, and I've run out of time, having prioritised getting the selectors DSL implemented.
The benchmarks are a bit weird, for 2 reasons:
In other rough benchmarks, we've seen JS plugins have a much higher cost. These benchmark numbers were originally from Cam's laptop, and I've replicated the result on my MacBook Air M3. But I ran into the same problem I had before that adding a JS plugin actually improves performance. This is clearly a nonsense - that's a side effect of either reduced file system contention, or some oddity of thread scheduling on M-series chips with efficiency cores. But getting to the bottom of that would take days, or maybe even weeks.
Oxlint is coming out at only 10x faster than ESLint. I think we'd expect a lot more than that. As a guess, it might be that ESLint in this case is not generating any errors, whereas Oxlint generates ~200 diagnostics. Printing diagnostics is really slow.
I actually don't think it matters that much if they're not super-scientific. Obviously, the performance is going to vary a lot depending on how many plugins, and how complex they are.
The benchmarks do still represent the thrust of the truth:
In my opinion, I don't think it's going to be possible to get a more solid benchmark in a reasonable amount of time, so our choices are: either go with them or, if we're uncomfortable with how unscientific it is, just remove them.
The main point of the blog post is the feature, not the performance.