We are thrilled to announce that Oxlint is now in beta release, after more than a year of development by the community!

This milestone represents a significant step forward in feature completeness, performance, and stability.

How to use ​

At this stage, Oxlint can be used to fully replace ESLint in small to medium projects.

For larger projects, our advice is to turn off ESLint rules via eslint-plugin-oxlint, and run Oxlint before ESLint in your local or CI setup for a quicker feedback loop.

To test Oxlint in your codebase, you can use the package manager of your choice at the root of your codebase:

$ npx oxlint@latest

$ pnpm dlx oxlint@latest

$ yarn dlx oxlint@latest

$ bunx oxlint@latest

$ deno run npm:oxlint@latest

For more detailed instructions on how to use Oxlint and integrate it with your project or editor, check out the installation guide.

Highlight of new features since general availability ​

• Significant performance improvements, up to twice as fast compared to the previous release
• Includes over 500 rules built-in, with no extra installation required
• Many rules from the typescript, unicorn, react, react-perf, nextjs, import, jsdoc, jsx-a11y, node, promise, jest, vitest plugins are now complete.
• Support for configuration via .oxlintrc.json files, including nested configuration files, using extends to share configuration between files, applying overrides to specific files, and more.
• Supports linting <script> content in .astro, .svelte and .vue files with no additional configuration needed.
• Allows applying automatic fixes and suggestions to files.

More rules, more performance ​

We have focused on making Oxlint more feature complete, supporting many of the most commonly used ESLint rules and plugins, but we have also made Oxlint much faster as well.

The first generally available (GA) release of Oxlint had 205 rules in total, with 70 of those being enabled by default. This beta release now includes 502 rules in total, with 99 of those being enabled by default (a 41% increase in the number of rules enabled by default).

Despite adding many new rules that are enabled by default, Oxlint is now much faster than it ever has been. Here are some benchmarks on some popular repositories:

Roadmap ​

One of the most commonly requested features for Oxlint is support for existing custom ESLint plugins. We have been busy working on the prerequisites for this feature, and to enable fast linter plugins written in JavaScript. We hope to have this feature available for the next major release, and more information to share about it in the near future.

We also are planning to continue improving the IDE/editor integrations, with improved support for VSCode, Zed, coc.nvim, and IntelliJ plugins.

Acknowledgements ​

Oxlint beta would not have been possible without the over 200 contributors to the project.

Special thanks goes to:

• @cam314, @mysteryven, and @shulaoda for implementing many sophisticated lint rules, testing, and constantly improving everything.
• @Sysix for maintaining eslint-plugin-oxlint.
• @DonIsaac for improving configuration, documentation and website, and for representing Oxc at SquiggleConf 2024.
• @leaysgur for the RegExp parser and JSDoc plugin.
• @u9g and @rzvxa for implementing control flow graph analysis.
• @branchseer for implementing the multi-file analysis runtime.
• @camchenry for implementing nested configuration support.

TL;DR: The first stable version Oxlint has been released! With a 50~100x performance improvement over ESLint, support for over 500 ESLint rules, and usage in major companies like Shopify, Airbnb, and Mercedes-Benz, you should give it a try. Get started now.

Oxlint is a Rust-powered linter for JavaScript and TypeScript, designed to be fast and easy to adopt. Since its initial announcement in December 2023, Oxlint has undergone significant improvements and is now releasing its first stable version, 1.0. In addition to the stable release, we also want to announce that Oxlint has a dedicated full-time maintainer, Cameron, and a growing core team working on maintaining and improving the linter.

Real-World Impact ​

We are extremely proud of the performance of Oxlint and its impact on real, large-scale codebases, which has led to reduced CI costs.

We are thankful for our 5,200 early adopters and for companies and projects such as:

• Shopify, where the front-end platform team uses Oxlint in the Shopify admin console.
• Airbnb, where they use multi-file analysis oxc/no-barrel-file and import/no-cycle on their 126,000+ files, which completes in 7s on CI. ESLint's implementation of these rules times out.
• Mercedes-Benz, where they observed a 71% decrease in lint time when switching from ESLint to Oxlint, with some project seeing up to a 97% speedup.
• Large Open Source projects, from runtimes like Bun to frameworks like Preact.

On the largest repository we found, Oxlint reported:

Finished in 22.5s on 264925 files with 101 rules using 10 threads.

Based on real-world cases posted on X and Bluesky, Oxlint runs at approximately 10,000 files per second, depending on the total number of threads used.

Quick Start ​

Oxlint is perfect for developers who want to start linting their code without spending hours configuring tools. With zero setup required, you can start catching issues immediately:

Run it, no config required.

$ npx oxlint@latest

$ pnpm dlx oxlint@latest

$ yarn dlx oxlint@latest

$ bunx oxlint@latest

$ deno run npm:oxlint@latest

While no setup or configuration is needed, Oxlint is configurable via an .oxlintrc.json file, which is useful for larger projects or projects that require more customization. This configuration format is based on ESLint v8’s flat config, making migration easy and familiar. Each source file is linted with the nearest applicable configuration, and you can use overrides to target specific glob patterns. You can also extend shared configs to keep teams consistent.

For projects already using ESLint, oxlint-migrate can be used to migrate an existing ESLint flat-config file to Oxlint. Additionally, eslint-plugin-oxlint can disable overlapping ESLint rules while both linters are used together. It is recommended to run oxlint && eslint to benefit from Oxlint's faster feedback cycle.

For more detailed instructions on how to use Oxlint and integrate it with your project or editor, check out the installation guide.

Versioning ​

Unlike libraries that ship runtime code, a linter only changes the diagnostics it returns. Oxlint adheres to semantic versioning:

• Patch releases: Bug fixes only.
• Minor releases: Expand rule coverage and diagnostics, without requiring configuration changes.
• Major releases: CLI or configuration changes, that may require migration. Note that minor releases can still break your CI if newly added rules uncover previously hidden issues. Learn more in our Versioning guide.

Highlights ​

Comprehensive Rule Coverage ​

Oxlint includes over 500 rules from various sources:

• Complete ESLint rule set, including TypeScript-specific rules from typescript-eslint (excluding type checked rules).
• Popular plugin rules from eslint-plugin-unicorn, eslint-plugin-jsdoc, eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jest, and eslint-plugin-import
• Unique Oxlint rules like bad comparison sequence, const comparisons, and only used in recursion

Flexible Configuration ​

Configure Oxlint through .oxlintrc.json files with support for:

• Nested configurations that apply to specific directories
• Override patterns for targeting specific file types or locations
• Shared configuration extending for team consistency

Editor Integration ​

First-class editor support with extensions for:

• VS Code
• IntelliJ IDEA and WebStorm
• Zed Editor
• Language server protocol support for other editors

Helpful Diagnostics ​

Oxlint is built to deliver clear, actionable error messages - not just describing the issue, but visualizing it and suggesting how to fix it.

Oxlint running in the terminal with detailed error reporting

Benchmark ​

Our benchmark reveals that Oxlint is around 50~100 times faster than ESLint with the same setup.

Roadmap ​

Oxlint 1.0 is just the beginning! While it is stable, we still have important features and improvements planned for future releases:

Custom Rules – JavaScript plugin support is coming soon, enabling teams to write custom rules that integrate seamlessly with Oxlint's architecture.

Performance Optimizations – Continued improvements to parsing and analysis speed.

Fine-grained (per-glob) configuration - ESLint v9 configuration

Acknowledgements ​

Oxlint 1.0 represents the collective effort of over 200 contributors who have shaped this project. We're grateful for every bug report, feature request, and code contribution.

Special recognition goes to:

• @branchseer for implementing the multi-file analysis runtime.
• @camc314, @mysteryven, and @shulaoda for implementing many sophisticated lint rules, testing, and constantly improving everything.
• @camchenry for implementing nested configuration support.
• @DonIsaac for improving configuration, documentation and website, and for representing Oxc at SquiggleConf 2024.
• @leaysgur for the RegExp parser and JSDoc plugin.
• @Sysix for maintaining eslint-plugin-oxlint and significant contributions to the language server and VSCode extension.
• @u9g and @rzvxa for implementing control flow graph analysis.

Join the Community ​

We'd love to hear your feedback on Oxlint and are excited to see how it helps improve your development workflow. Connect with us:

• Discord: Join our community server for real-time discussions
• GitHub: Share feedback on GitHub Discussions
• Issues: Report bugs or request features on our issue tracker

Your feedback drives Oxlint's evolution.

Give It a Try ​

To get started, follow the installation guide, or learn more about the Oxc project.

We're thrilled to announce type-aware linting in oxlint!

The long-awaited no-floating-promises and related rules are here.

This preview release aims to engage with the community for collaboration and discussion by documenting our decision process and technical details.

Quick Start ​

If oxlint is already configured, install oxlint-tsgolint and run oxlint with the --type-aware flag:

pnpm add -D oxlint-tsgolint@latest
pnpm dlx oxlint --type-aware

If oxlint is not configured but you want to see no-floating-promises in action:

pnpm add -D oxlint-tsgolint@latest
pnpm dlx oxlint@latest --type-aware -A all -D typescript/no-floating-promises

We expect to see, for example:

 × typescript-eslint(no-floating-promises): Promises must be awaited, end with a call to .catch, end with a call to .then with a rejection handler or be explicitly marked as ignored with the `void` operator.
   ╭─[packages/rolldown/src/api/watch/watcher.ts:30:7]
29 │       await this.close();
30 │       originClose();
   ·       ──────────────
31 │     };
   ╰────

Please visit our usage guide for more configuration options.

Performance ​

Our testing shows that repositories which previously took a minute to run with typescript-eslint now complete in less than 10 seconds.

This is achieved by leveraging typescript-go, the 10x faster TypeScript written in Go.

Using projects from oxc-ecosystem-ci:

Type-Aware Linting ​

Please refer to Rust-Based JavaScript Linters: Fast, But No Typed Linting Right Now to understand the current status of type-aware linting in the ecosystem.

Technical Details ​

The core of this new functionality is oxc-project/tsgolint.

The tsgolint project was initially prototyped as typescript-eslint/tsgolint. However, the typescript-eslint team decided not to allocate development resources to this prototype, as they plan to continue their work on typescript-eslint for typed linting with ESLint.

@boshen reached out to @auvred for a forked, scoped-down version adapted for oxlint. This version would only contain type-aware rules without the sophisticated configuration resolution a full linter would require.

@auvred generously offered to continue its development under the Oxc organization.

Architecture ​

oxlint (written in Rust) and tsgolint (written in Go) are compiled into their own binaries.

oxlint serves as the "frontend" for tsgolint, handling the CLI, path traversal, ignore logic, and diagnostic printing.

tsgolint acts as the backend for oxlint, accepting paths and configuration as input and outputting structured diagnostics.

This creates a simple pipeline:

oxlint CLI (returns paths + rules + configuration)
  -> tsgolint (returns diagnostics)
  -> oxlint CLI (prints diagnostics)

tsgolint ​

tsgolint does not communicate with typescript-go via public APIs.

Instead, it compiles typescript-go by shimming its internal APIs to make them public.

All type-aware rules are written directly against these shimmed APIs.

While this isn't the recommended approach for accessing internals, it works!

Decision Process ​

Write our own type checker ​

Previous abandoned attempts to implement a type-checker included:

• My own attempt at writing type inference
• Integrate ezno type checker by @kaleidawave
• stc by @kdy1
• There are also many attempts in the community that did not go far.

Additionally, there's the work-in-progress Biome 2.0 with its own type-inference implementation.

We determined that writing our own type-inferencer or type-checker was not feasible due to the challenge of keeping up with a fast-moving target like TypeScript.

Communication with TypeScript Compiler ​

Prior to typescript-go, projects added plugin interfaces to TypeScript's public API by either mapping its AST to estree or directly traversing the TypeScript AST. Examples include:

• typescript-eslint
• tsslint
• tsl

We also explored inter-process communication with oxlint but abandoned the idea.

With typescript-go, the TypeScript team is leaning towards encoding the TypeScript AST and decoding it on the JavaScript side through inter-process communication.

While these approaches work, they still incur:

• Performance issues of varying degrees that don't suit oxlint's performance characteristics.
• The cost of maintaining an AST mapping from TypeScript's AST.

Considerations ​

While tsgolint solves the performance issue, there are other technical challenges that need to be addressed.

Requirement for a Different TypeScript Version ​

We plan to release snapshots of typescript-go versions and align their version numbers with TypeScript. You will then be able to install oxlint-typescript with the correct TypeScript version.

The downside of this approach is that you may need to upgrade TypeScript if oxlint-tsgolint requires changes.

Maintenance cost of tsgolint ​

Shimming TypeScript's internal APIs carries some risk. However, the TypeScript AST and its visitor are actually quite stable. We accept this risk and will fix breaking changes when upgrading typescript-go.

Our typescript-go version is synced every day.

Performance Issues ​

tsgolint currently does not perform well on large monorepos with hundreds of projects or lots of project references.

It may hang with a deadlock or cause OOM (out-of-memory) if a bug is encountered.

We are actively addressing these issues, profiling and submitting improvements to typescript-go, benefiting all typescript-go users.

Our core team member @camc314 has already submitted many PRs that made several code paths significantly faster.

v1.0 Release ​

For tsgolint v1.0, we will address:

• performance issue for large monorepos
• be able to configure individual rules
• correctness of each individual rules
• IDE support
• overall stability

Acknowledgements ​

We'd like to extend our gratitude to:

• The TypeScript team for creating typescript-go.
• The typescript-eslint team for their heartwarming support.
• @auvred for creating tsgolint.
• @camchenry for the oxlint + tsgolint integration.
• @camc314 for work on performance issues.

Join the Community ​

We'd love to hear your feedback on oxlint and type-aware linting and are excited to see how it helps improve your development workflow.

Connect with us:

• Discord: Join our community server for real-time discussions
• GitHub: Share feedback on GitHub Discussions
• Issues: Report oxlint bugs to oxc and type-aware linting bugs to tsgolint.

Next steps ​

Install oxlint:

pnpm add -D oxlint@latest oxlint-tsgolint@latest
pnpm dlx oxlint --init # generate .oxlintrc.json

or follow the installation guide.

Use the --type-aware CLI flag.

pnpm dlx oxlint --type-aware

And play around with any of the type-aware rules in .oxlintrc.json:

{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "rules": {
    "typescript/await-thenable": "error",
    "typescript/no-array-delete": "error",
    "typescript/no-base-to-string": "error",
    "typescript/no-confusing-void-expression": "error",
    "typescript/no-duplicate-type-constituents": "error",
    "typescript/no-floating-promises": "error",
    "typescript/no-for-in-array": "error",
    "typescript/no-implied-eval": "error",
    "typescript/no-meaningless-void-operator": "error",
    "typescript/no-misused-promises": "error",
    "typescript/no-misused-spread": "error",
    "typescript/no-mixed-enums": "error",
    "typescript/no-redundant-type-constituents": "error",
    "typescript/no-unnecessary-boolean-literal-compare": "error",
    "typescript/no-unnecessary-template-expression": "error",
    "typescript/no-unnecessary-type-arguments": "error",
    "typescript/no-unnecessary-type-assertion": "error",
    "typescript/no-unsafe-argument": "error",
    "typescript/no-unsafe-assignment": "error",
    "typescript/no-unsafe-call": "error",
    "typescript/no-unsafe-enum-comparison": "error",
    "typescript/no-unsafe-member-access": "error",
    "typescript/no-unsafe-return": "error",
    "typescript/no-unsafe-type-assertion": "error",
    "typescript/no-unsafe-unary-minus": "error",
    "typescript/non-nullable-type-assertion-style": "error",
    "typescript/only-throw-error": "error",
    "typescript/prefer-promise-reject-errors": "error",
    "typescript/prefer-reduce-type-parameter": "error",
    "typescript/prefer-return-this-type": "error",
    "typescript/promise-function-async": "error",
    "typescript/related-getter-setter-pairs": "error",
    "typescript/require-array-sort-compare": "error",
    "typescript/require-await": "error",
    "typescript/restrict-plus-operands": "error",
    "typescript/restrict-template-expressions": "error",
    "typescript/return-await": "error",
    "typescript/switch-exhaustiveness-check": "error",
    "typescript/unbound-method": "error",
    "typescript/use-unknown-in-catch-callback-variable": "error"
  }
}

Earlier this year we asked for input from the community 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!

Key features ​

• ESLint-compatible plugin API. Oxlint will be able to run many existing ESLint plugins without modification.
• An alternative API which is slightly different, and unlocks better performance.

What this is and isn't ​

This preview release is just the beginning. It is important to note that:

• This initial release does not implement all of ESLint's plugin API.
• 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, so many existing ESLint rules will already work. But token-related APIs are absent, so stylistic (formatting) rules will not.

We invite users to take it for a spin, give feedback, and inform our priorities for the next phase of development.

This blog post covers ​

1. How to use it.
2. What's coming next.
3. Some of the technical details that enable our "have cake and eat it" approach of providing both ESLint compatibility and excellent performance.

Quick Start ​

Install Oxlint in your project:

pnpm add -D oxlint

Write a custom JS plugin:

// plugin.js

// The simplest rule of all - no debugger
const rule = {
  create(context) {
    return {
      DebuggerStatement(node) {
        context.report({
          message: "No debugger!",
          node,
        });
      },
    };
  },
};

const plugin = {
  meta: {
    name: "best-plugin-ever",
  },
  rules: {
    "no-debugger": rule,
  },
};

export default plugin;

Create config file enabling the plugin:

// .oxlintrc.json
{
  "jsPlugins": ["./plugin.js"],
  "rules": {
    "best-plugin-ever/no-debugger": "error"
  }
}

Add a file to be linted:

// foo.js
debugger;

Run Oxlint:

pnpm oxlint

Expect to see:

 x best-plugin-ever(no-debugger): No debugger!
  ,-[foo.js:1:1]
1 | debugger;
  : ^^^^^^^^^
  `----

For further details on authoring plugins, see the docs.

Alternative API ​

Oxlint also offers a slightly different API which unlocks better performance.

This alternative API produces plugins which are compatible with ESLint, as well as Oxlint.

Example rule that flags files containing more than 5 class declarations:

ESLint version ​

const rule = {
  create(context) {
    let classCount = 0;

    return {
      ClassDeclaration(node) {
        classCount++;
        if (classCount === 6) {
          context.report({ message: "Too many classes", node });
        }
      },
    };
  },
};

Alternative API version ​

import { defineRule } from "oxlint";

const rule = defineRule({
  createOnce(context) {
    // Define counter variable
    let classCount;

    return {
      before() {
        // Reset counter before traversing AST of each file
        classCount = 0;
      },
      // Same as before
      ClassDeclaration(node) {
        classCount++;
        if (classCount === 6) {
          context.report({ message: "Too many classes", node });
        }
      },
    };
  },
});

The differences ​

1. Wrap the rule object in defineRule(...).

- const rule = {
+ const rule = defineRule({

2. Use createOnce instead of create.

-   create(context) {
+   createOnce(context) {

3. Move any per-file setup from body of create into before hook.

-     let classCount = 0;
+     let classCount;

      return {
+       before() {
+         classCount = 0; // Reset counter
+       },
        ClassDeclaration(node) {
          classCount++;
          if (classCount === 6) {
            context.report({ message: "Too many classes", node });
          }
        },
      };
    },
  });

This is the only significant difference - create (ESLint's method) is called repeatedly for each file, whereas createOnce is called once only.

All other APIs behave exactly the same as in ESLint.

The reasons why this alternative API has potential to greatly improve performance are explained in the docs.

Performance ​

As mentioned above, performance has not been our focus in this initial preview release of Oxlint JS plugins. Our primary goal has been to fill out enough of the API for JS plugins to be useful in real world projects, and gather feedback from early adopters.

Performance at present is decent, but not by any means stellar.

However - and we feel this is the important point - our prototype of the next version demonstrates that the architectural design we've settled on is capable of exceptional performance, once various optimizations are added into the mix (see Under the hood).

We'll be applying those optimization over the course of the next few months, and users will see multiple x speed-ups compared to the current version.

That said, even without those optimizations, Oxlint's performance is still competitive.

Oxlint vs ESLint linting a medium-sized TypeScript project vuejs/core:

hyperfine -i --warmup 3 \
  './node_modules/.bin/oxlint --silent' \
  './node_modules/.bin/oxlint -c .oxlintrc-with-custom-plugin.json --silent' \
  'USE_CUSTOM_PLUGIN=true ./node_modules/.bin/eslint .' \
  'USE_CUSTOM_PLUGIN=true ./node_modules/.bin/eslint . --concurrency=auto'

In this example, adding a simple JS plugin to Oxlint does have a significant cost, but Oxlint is still 15x faster than ESLint, even using ESLint's new multi-threaded runner.

Obviously, more complicated JS plugins, or many of them, will have a higher performance cost.

Features ​

Oxlint supports most of ESLint's APIs which are typically used in plugins/rules which rely only on AST inspection. That includes most "fix code"-type rules.

It does not yet support token-based APIs, so stylistic (formatting) rules will not work yet.

Supported ​

• AST traversal
• AST exploration (node.parent, context.sourceCode.getAncestors)
• Fixes
• Selectors (ESLint docs)
• SourceCode APIs (e.g. context.sourceCode.getText(node))

Not supported yet ​

• Language server (IDE) support
• Rule options
• Suggestions
• Scope analysis (implemented since v1.25.0)
• SourceCode APIs related to tokens and comments (e.g. context.sourceCode.getTokens(node))
• Control flow analysis

What's next ​

Over the next few months, we will be:

1. Filling out the plugin API surface ​

Aim is to support 100% of ESLint's plugin API surface, so that Oxlint will eventually be able to run any ESLint plugin without modification.

2. Improving performance ​

Performance is already decent, but we have proven during our prototyping many significant performance gains from further optimizations. We will apply them, and make JS plugins in Oxlint run at as close to Rust speed as we can get.

Under the hood ​

The rest of this post is not necessary to use JS plugins with Oxlint. But if you're interested in the geeky details of how our implementation works, read on...

The big question: To ESLint compat or not to ESLint compat? ​

The question which we posed to the community earlier this year was whether Oxlint should aim for an ESLint-compatible plugin API or not.

Obviously, an ESLint-compatible interface is ideal in terms of familiarity and ease of migration from ESLint.

However, Oxlint is known for its excellent performance, and compromising that too much would not be desirable.

The main aim of our prototyping work over past few months has been to quantify what is the trade-off between performance and ESLint compatibility, and to investigate if there's a "have cake and eat it" solution which satisfies both - providing an ESLint-compatible API and acceptable performance ("acceptable" here means pretty damn fast!)

We believe that through a combination of different approaches, we've found a way to satisfy both demands.

Alternative API ​

See explanation in docs of why this API unlocks potential for higher performance.

Raw transfer ​

Tools like Oxc represent the code of a JS/TS file as an "AST" (abstract syntax tree). ASTs are really big - much much larger than the source code they represent.

Typically, the biggest barrier to performant interop between JS and native languages like Rust is the serialization and deserialization involved in transferring such large data structures between the "two worlds".

The simplest and most common way to move an AST between JS and Rust is: Serialize the AST to JSON, send it across to JS as a string and then "rehydrate" it again with JSON.parse. But this is extremely slow. Often the cost of these conversions is so high that they massively outweigh the performance gain of using native code in the first place. Other serialization formats are more efficient than JSON, but they still have a sizeable overhead.

We have developed a scheme "raw transfer" which cuts out serialization altogether, by using Rust's native memory layout as the serialization format (more details on how it works here).

"Raw transfer" is the base of the current implementation of JS plugins.

Lazy deserialization ​

The 2nd biggest enemy of good perf, particularly when running JS across multiple CPU cores in worker threads, is the garbage collector. Every object you create also needs to be destroyed to recover its memory. In JS, this is the job of the garbage collector. JS engines like V8 are highly optimized, but still garbage collection is an expensive process, and GC "steals" CPU resources from the actual workload.

We have prototyped an AST visitor which deserializes the AST lazily, and only deserializes the parts of the AST which actually need to be.

For example, if your lint rule relates to class declarations, this visitor will fly through most of the AST without doing much, and will only create JS objects for ClassDeclaration AST nodes, which are then passed to the rule's code to process. For the rest of the AST (variable declarations, if statements, functions, etc) there is no need to create node objects at all.

This has 2 effects:

1. Raw transfer cuts the cost of serialization to zero. Laziness dramatically reduces the other side (deserialization) too.
2. Greatly reduced garbage collector pressure.

Deno has taken a similar approach, which is explained brilliantly in Marvin Hagemeister's blog post, and Deno lint has a superbly efficient implementation.

However, we've found that it's the combination of lazy deserialization with "raw transfer" which delivers really good performance. Our tests have found that, with both these overheads removed, JS plugins can run at much greater speed.

This optimization is not yet included in current version of JS plugins. We will implement it in a future version.

Try it out! ​

Please try out JS plugins and report your experience. All feedback - either positive or negative - is gratefully received.

In particular, if you find that Oxlint is lacking some of the APIs you need for your plugins to work, please let us know. We'll be filling in the gaps in the API over the next few months, and will prioritise those for which there's greatest demand.

Happy linting!

Edit: 18th Oct 2025 ​

The original version of this blog post published on 9th Oct contained benchmarks results which showed the performance of Oxlint JS plugins to be far better than they are in reality. This was the result of a bug in Oxlint which was causing JS plugins to be skipped on many files in certain circumstances when the config contains overrides. This bug lead to the performance of JS plugins being way overestimated in the benchmarks we quoted.

We sincerely apologise for this mistake, and thank Herrington Darkholme for pointing out the error.

We’re excited to announce the alpha release of Oxfmt, a Rust-powered, Prettier-compatible code formatter. This first release focuses on JavaScript and TypeScript, with support for additional languages coming soon.

Oxfmt is designed with these goals in mind:

• Performance: More than 30× faster than Prettier and more than 3× faster than Biome on an initial run without a cache (benchmark).
• Compatibility: Prettier-compatible, so you can adopt Oxfmt in existing projects easily.
• Developer Experience: Upcoming features include import sorting, expanded formatting options, and support for Prettier plugins.

Quick Start ​

Add oxfmt to your project:

npm add -D oxfmt@latest

pnpm add -D oxfmt@latest

yarn add -D oxfmt@latest

bun add -D oxfmt@latest

deno add -D npm:oxfmt@latest

Oxfmt follows Prettier’s configuration format. If you are using Prettier with a JSON configuration file, you can rename it to .oxfmtrc.jsonc:

cp .prettierrc.json .oxfmtrc.jsonc

You can also start from this .oxfmtrc.jsonc configuration example:

{
  "$schema": "./node_modules/oxfmt/configuration_schema.json",
  // Use 80 if migrating from Prettier; 100 is the Oxfmt default!
  "printWidth": 80,
  "ignorePatterns": [] // Same as `.prettierignore`
}

Next, add oxfmt to your package.json scripts:

"scripts": {
  "format": "oxfmt"
}

Alternatively, refer to the installation guide for detailed instructions.

Performance ​

Oxfmt is incredibly fast. Our benchmark results on the Outline repository show:

• Over 30× faster than Prettier’s experimental CLI without cache
• Over 20× faster than Prettier using Oxc’s parser through @prettier/plugin-oxc
• Over 3× faster than Biome, another Rust-based formatter

For detailed benchmark setup, please refer to the following repository:

oxc-project/bench-formatter
https://github.com/oxc-project/bench-formatter

Design ​

The Oxc team prioritizes compatibility with existing ecosystems, making migrations straightforward, even for large codebases.

Code formatting results ​

Oxfmt matches Prettier’s JavaScript formatting. If you are migrating to Oxfmt today, you shouldn’t see any formatting differences compared to Prettier.

You might see minor differences when migrating from older versions of Prettier (See an example migration) because we identified areas in which Prettier’s formatting could be improved. We have been actively collaborating with the Prettier team by submitting bug reports and pull requests directly to Prettier. Many of these improvements landed in the recent Prettier 3.7 release.

Oxfmt currently passes around 95% of Prettier’s JavaScript and TypeScript tests, and we hope to work with the Prettier team to converge on formatting over time.

printWidth: 100 by default ​

We chose printWidth: 100 as the default line length instead of Prettier's 80. Our reasons include:

• TypeScript code tends to be longer than JavaScript due to type annotations.
• Import statements often contain many items.
• Larger screens provide more horizontal space.
• Results in slightly fewer LLM tokens.

While Oxfmt remains compatible with Prettier, it uses a different default print width of 100 characters. If you want to avoid large diffs when migrating from Prettier, explicitly set the print width to 80.

ignorePatterns ​

While Oxfmt supports .prettierignore, it also supports an ignorePatterns configuration option to consolidate all configuration into a single file.

Configuration ​

Prettier JSON configuration files are compatible with Oxfmt. In the simplest case, migrating your config looks like this:

cp .prettierrc.json .oxfmtrc.jsonc

If your editor supports the JSON language server, you can start with this minimal template after adding oxfmt to your devDependencies:

{
  "$schema": "./node_modules/oxfmt/configuration_schema.json",
  "ignorePatterns": []
}

While we don’t yet support all of Prettier’s configuration options in this alpha release, we do support the following major options: printWidth, tabWidth, useTabs, semi, singleQuote, quoteProps, jsxSingleQuote, trailingComma, bracketSpacing, objectWrap, bracketSameLine, arrowParens, endOfLine, and singleAttributePerLine.

Check out all of the options in our documentation.

Terminal Output ​

Oxfmt's default behavior is equivalent to prettier . --write, providing the same UX as cargo fmt and producing no output. You can use --check to display formatting differences and enforce oxfmt usage in CI pipelines.

Beta Release Plans ​

Here are our plans for the beta release:

• Support more file formats - like .json files
• Add support for embedded language formatting - css in js or graphql in js
• Built-in sorting and aesthetics features, such as sort imports
• Prettier plugins
• Node.js API for Oxfmt
• Disable newline at the end of file
• --migrate prettier
• … and your feature requests

You can track our progress towards the beta release here:

Formatter Beta · Milestone #15 · oxc-project/oxc
https://github.com/oxc-project/oxc/milestone/15

We also plan to relax some of the formatting opinions in future versions.

Next Steps ​

See the full installation guide in the Oxfmt docs.

Reporting Issues ​

For formatting differences, please refer to https://github.com/oxc-project/oxc/discussions/14669. Additionally, known issues are distinguished by labels.

If you find any other issues, please create an issue with dedicated template on GitHub.

Join the Community ​

RFC: Formatter · oxc-project/oxc · Discussion #13608
https://github.com/oxc-project/oxc/discussions/13608

We welcome your feedback to help make Oxfmt even better!

Acknowledgements ​

Oxfmt builds on a fork of the biome_formatter infrastructure, and we’d like to thank the Biome team, especially @ematipico and @MichaReiser. We’d also like to thank the Prettier team and @fisker for collaborating with us on formatting compatibility.

We're excited to announce the alpha release of type-aware linting in Oxlint!

Overview ​

Following our technical preview in August, we're excited to announce that type-aware linting has reached alpha status. This milestone brings significant improvements in stability, configurability, and rule coverage.

Type-aware linting enables powerful rules like no-floating-promises, no-misused-promises, and await-thenable that catch bugs by utilizing TypeScript's type system. With 43 type-aware rules now available, you can catch entire categories of runtime errors before they happen.

In this post:

• Quick Start - Get started with type-aware linting in minutes
• Performance - See how much faster type-aware linting is compared to ESLint
• What's new since the technical preview - New features and improvements
• Technical details - How type-aware linting works under the hood
• What's next - Upcoming improvements for the beta release

Quick Start ​

Install oxlint and oxlint-tsgolint, then run with the --type-aware flag:

npm add -D oxlint oxlint-tsgolint@latest
npx oxlint --type-aware

pnpm add -D oxlint oxlint-tsgolint@latest
pnpm oxlint --type-aware

yarn add -D oxlint oxlint-tsgolint@latest
yarn oxlint --type-aware

bun add -D oxlint oxlint-tsgolint@latest
bunx oxlint --type-aware

To try a specific type-aware rule without other configuration (oxlint-tsgolint must be installed globally or locally already):

npx oxlint --type-aware -A all -D typescript/no-floating-promises

pnpx oxlint --type-aware -A all -D typescript/no-floating-promises

yarn oxlint --type-aware -A all -D typescript/no-floating-promises

bunx oxlint --type-aware -A all -D typescript/no-floating-promises

For more configuration options, see our usage guide.

Performance ​

Benchmarks were performed on a MacBook Pro M2 Max 12 Cores (8 performance and 4 efficiency).

Our performance testing shows that oxlint with type-aware linting is around 10 times faster than eslint with typescript-eslint. Take a look at our performance benchmarks for more details.

Oxlint can also be used to typecheck your codebase while linting. This avoids a duplicate work, as much of the type information is already computed during type-aware linting.

What's new since the technical preview? ​

Support for type-checking while linting ​

tsgolint now supports emitting type checking errors from TypeScript while linting. Since type-aware rules already require checking all of the types within a file, we are able to use this existing type information rather than discarding it. This means that in some cases, it is possible to skip doing a separate type-check command altogether (e.g., tsc --noEmit), reducing total time spent doing linting and type-checking in CI.

This is an experimental feature, but you can enable it by adding the --type-check and --type-aware flag to the oxlint command:

$ oxlint --type-aware --type-check

  × typescript(TS2322): Type 'number' is not assignable to type 'string'.
   ╭─[index.ts:1:7]
 1 │ const message: string = 1
   ·       ───────
   ╰────

Rule configuration support in oxlint ​

Type-aware rules that run in tsgolint can be configured in oxlint just like any other lint rule. For example, you can configure the no-floating-promises rule to allow certain safe calls or ignore void:

{
  "rules": {
    "typescript/no-floating-promises": [
      "error",
      {
        "ignoreVoid": true,
        "allowForKnownSafePromises": [
          { "from": "file", "name": "SafePromise" },
          { "from": "lib", "name": "PromiseLike" }
        ]
      }
    ]
  }
}

The configuration options are aligned with what typescript-eslint supports and documentation can be found in the configuration section for each rule (like no-floating-promises).

Inline disable comment support in oxlint ​

Rules that run in tsgolint can now be disabled similar to any other oxlint rule by placing a comment in the file or on a line:

/* oxlint-disable typescript/no-floating-promises */

// oxlint-disable-next-line typescript/no-floating-promises
[1, 2, 3].map(async (x) => x + 1);

More supported rules ​

We've continued to make progress on porting popular rules from typescript-eslint which you can now use via oxlint. tsgolint, combined with oxlint, currently supports 43 type-aware rules.

Since the initial preview, support for the following rules has also been added:

• no-deprecated (one of the most commonly requested rules)
• prefer-includes
• strict-boolean-expressions

TypeScript program diagnostics are now reported ​

Previously, if TypeScript failed to create and parse a program, these errors were not reported which led to confusion around why linting was not working. Now, we report any issues with creating a program as a diagnostic, including configuration issues in tsconfig.json files.

For example, if a tsconfig.json file contains baseUrl, that will be reported as an error, since baseUrl has been removed from TypeScript in v7.0:

$ oxlint --type-aware

  × typescript(tsconfig-error): Invalid tsconfig
   ╭─[tsconfig.json:4:3]
 3 │     "compilerOptions": {
 4 │         "baseUrl": ".",
   ·         ─────────
 5 │         "experimentalDecorators": true,
   ╰────
  help: Option 'baseUrl' has been removed. Please remove it from your configuration.
        See https://github.com/oxc-project/tsgolint/issues/351 for more information.

Automatic fixes for type-aware rules ​

Type-aware rules now support automatic fixes via the --fix flag. When you run oxlint --type-aware --fix, fixable diagnostics from tsgolint are applied just like regular oxlint fixes. This brings full parity with non-type-aware rules for the fix workflow.

Technical details ​

Architecture ​

Type-aware linting in Oxlint uses a unique two-binary architecture:

oxlint CLI (Rust)
  ├─ Handles file traversal, ignore logic, and diagnostics
  ├─ Runs non-type-aware rules and custom JS plugins
  ├─ Passes paths and configuration to tsgolint
  └─ Formats and displays results

tsgolint (Go)
  ├─ Uses typescript-go directly for type checking
  ├─ Executes type-aware rules
  └─ Returns structured diagnostics

This design keeps Oxlint's core fast while leveraging TypeScript's type system through typescript-go. The frontend-backend separation means oxlint controls the user experience while tsgolint handles the heavy lifting of type analysis.

TypeScript compatibility ​

tsgolint is based on typescript-go, Microsoft's Go-based rewrite that will become TypeScript v7.0. For more details on TypeScript 7's progress, see the official TypeScript blog post. This means that you might encounter some features which are no longer supported.

Important compatibility notes:

• Only TypeScript 7.0+ features are supported
• Pre-7.0 syntax and deprecated features are not supported
• Legacy tsconfig.json options like baseUrl have been removed in TypeScript 7.0

If you're using deprecated features from TypeScript 6.0 or earlier, you'll need to migrate your codebase first. See the TypeScript migration guide for help updating deprecated tsconfig options.

Implementation details ​

tsgolint doesn't use typescript-go's public APIs. Instead, it compiles typescript-go by shimming internal APIs to make them accessible. We actively track typescript-go updates and fix breaking changes as needed.

Our typescript-go fork is synced regularly using renovatebot, ensuring we stay current with the latest improvements and fixes. Once TypeScript 7.0 is officially released, we will track stable releases rather than the tip of the main branch.

What's next ​

We're actively working on the following improvements for the beta release:

• More supported rules - Currently we support 43 out of the 59 type-aware rules from typescript-eslint. As we head towards a beta release, we plan to continue expanding rule coverage.
• Performance and memory usage improvements - We're going to continue to optimize performance, especially for very large monorepos.

Acknowledgements ​

We'd like to extend our gratitude to:

• The TypeScript team for creating typescript-go.
• The typescript-eslint team for their heartwarming support.
• @auvred for creating tsgolint.
• @camchenry for continued performance work, as well as implementing rule option support.

Try it out ​

Ready to get started? Head to the Quick Start section above to install and run type-aware linting.

We'd love to hear your feedback on type-aware linting and are excited to see how it helps improve your development workflow.

Connect with us:

• Discord: Join our community server for real-time discussions
• GitHub: Share feedback on GitHub Discussions
• Issues: Report oxlint bugs to oxc and type-aware linting bugs to tsgolint.

We are excited to announce that Oxfmt has reached beta.

Oxfmt is a Rust-powered, Prettier-compatible code formatter built for the JavaScript ecosystem. It is designed to deliver full compatibility with modern tooling while dramatically improving performance.

In benchmarks, Oxfmt is more than 30× faster than Prettier and 3× faster than Biome on an initial run without caching. See the full benchmark results.

Since the December alpha release, we have expanded support for additional file formats, added embedded language formatting, introduced import sorting, integrated Tailwind CSS support, and delivered numerous stability and compatibility improvements.

Oxfmt has already seen broad adoption across the ecosystem. Projects using Oxfmt include: openclaw/openclaw, vuejs/core, vercel/turborepo, huggingface/huggingface.js, getsentry/sentry-javascript, npmx-dev/npmx.dev and many more.

Getting Started ​

Install oxfmt as a dev dependency:

pnpm add -D oxfmt

Add scripts to package.json:

{
  "scripts": {
    "fmt": "oxfmt",
    "fmt:check": "oxfmt --check"
  }
}

Format files:

pnpm run fmt

Check formatting without writing files:

pnpm run fmt:check

Migrating from Prettier ​

Install, migrate your config, and reformat in a single command:

pnpm add -D oxfmt && pnpm oxfmt --migrate prettier && pnpm oxfmt

For the full migration guide, see Migrate from Prettier.

AI Migration Prompt ​

Alternatively, you can copy this prompt to your AI coding assistant to migrate your project:

Migrate this project from Prettier to Oxfmt following https://oxc.rs/docs/guide/usage/formatter.html:
1. Install oxfmt and run `oxfmt --migrate prettier`
2. Update package.json scripts to use oxfmt
3. Update CI workflows to use `oxfmt --check`
4. Update lint-staged to use `oxfmt --no-error-on-unmatched-pattern`
5. Run oxfmt to reformat all files
6. Uninstall prettier and related packages
7. Update editor settings for oxfmt
8. Update CONTRIBUTING.md, AGENTS.md, or CLAUDE.md if they mention prettier

For more detailed instructions, check out the Oxfmt docs.

Highlights of New Features Since Alpha ​

100% Prettier Compatibility ​

Oxfmt now passes 100% of Prettier's JavaScript and TypeScript conformance tests. For the few remaining formatting inconsistencies, we have reported them to the Prettier team and are collaborating to converge on the expected behavior.

This means you can migrate from Prettier to Oxfmt with confidence that your code will be formatted identically. If you encounter any uncovered cases, please report them.

Additional File Formats ​

Oxfmt now formats JavaScript, JSX, TypeScript, TSX, JSON, JSONC, JSON5, YAML, TOML, HTML, Angular, Vue, CSS, SCSS, Less, Markdown, MDX, GraphQL, Ember, and Handlebars. This means you can use a single formatter for your entire project.

Tailwind CSS Integration ​

Automatic Tailwind CSS class sorting is supported for both JS/TS and non-JS/TS files. The functionality of prettier-plugin-tailwindcss is built-in, so the plugin is no longer required.

Import Sorting ​

Built-in import sorting is now available with configurable options:

• ignoreCase - Case-insensitive sorting
• sortSideEffects - Sort side-effect imports
• newlinesBetween - Control blank lines between import groups
• groups - Custom sort order groups
• customGroups - Define custom grouping rules

For more options, please see the full reference.

package.json Sorting ​

Automatic package.json field sorting is enabled by default, keeping your package.json files consistently organized.

Embedded Language Formatting ​

Format code embedded in template literals:

• CSS-in-JS with styled-components-like syntaxes, styled-jsx and CSS prop support
• Angular @Component template and styles

Node.js API ​

A programmatic API is now available:

import { format, type FormatOptions } from "oxfmt";

const input = `let a=42;`;
const options: FormatOptions = {
  semi: false,
};

const { code } = await format("a.js", input, options);
console.log(code); // "let a = 42"

CLI Changes ​

• --init - Bootstrap a new configuration file
• --migrate prettier - Migrate from Prettier configuration
• --migrate biome - Migrate from Biome configuration
• --stdin-filepath - Specify filepath for stdin input
• Glob pattern expansion support - oxfmt './packages/**/*.{js,jsx}'

Config Changes ​

• overrides - Apply different options to specific file patterns
• insertFinalNewline - Control trailing newlines
• .editorconfig support for insert_final_newline

Editor Support ​

Oxfmt works in all supported editors: VS Code, Cursor, Zed, IntelliJ IDEA, WebStorm, Neovim, and any editor with LSP support.

Roadmap ​

We are continuing to improve Oxfmt towards a stable release:

• Prettier plugins support
• Improve xxx-in-js formatting
• Stability
• Performance optimizations

Next Steps ​

See the full installation guide in the Oxfmt docs.

Reporting Issues ​

For formatting differences, please refer to the formatting differences discussion.

Join the Community ​

We'd love to hear your feedback on Oxfmt. Connect with us:

• Discord: Join our community server for real-time discussions
• GitHub: Share feedback on the Formatter RFC
• Issues: Report bugs or request features on our issue tracker

JavaScript plugins for Oxlint have reached alpha - and we expect 80% of ESLint users can now switch to Oxlint and have it "just work".

Oxlint already has over 650 popular lint rules implemented in Rust, running at native speed. JS plugins fill in the gaps - an ESLint-compatible plugin API, letting you run existing ESLint plugins and write your own custom rules, all within Oxlint. Native performance for most rules, full flexibility for the rest.

Since the first technical preview last year, we've filled out almost the entire ESLint plugin API, added TypeScript plugin support, auto-fixes, IDE integration, and major performance gains.

This means many teams can replace ESLint with Oxlint, without rewriting their lint rules.

This alpha release marks the point where we feel JS plugins are ready for adoption in real world projects.

Most projects should find that Oxlint can now act as a drop-in replacement for ESLint, with straightforward migration, and large reduction in linting time.

Features ​

• Run most existing ESLint plugins without modification.
• Write your own custom lint rules in JavaScript or TypeScript.
• Get auto-fixes and suggestions from JS plugin rules.
• See JS plugin diagnostics live in your IDE via the language server.

How reliable is it? ​

Oxlint JS plugins support is tested against the full test suite of ESLint itself, and also against a wide selection of ESLint plugins, including:

* excluding type-aware rules

If a plugin isn't in the list above, it will very likely still work - it just isn't included in our conformance test suite yet.

ESLint's own tests cover the entire API surface, so a 100% pass rate gives us confidence that we've covered corner cases, as well as the happy path. Please try it out and let us know!

Oxlint is already used in production by many companies and projects, including Midjourney, Preact, Posthog, Outline, and Actual.

What it can't do (yet) ​

• Limited support for front-end frameworks' custom file formats (e.g. Svelte, Vue, Angular) - coming later this year.
• No custom type-aware rules (TypeScript-ESLint's rules are already built into Oxlint via type-aware linting).
• Some users have found the experience on Windows sub-par. Out of memory errors are a known issue, specifically on Windows. We're working on it. In the meantime, if you hit this problem, we recommend running Oxlint in WSL, if that's an option.

You can follow our progress towards filling these gaps on the tracking issue.

Getting Started ​

Install oxlint as a dev dependency:

pnpm add -D oxlint

Add a script to package.json:

{
  "scripts": {
    "lint": "oxlint"
  }
}

Create a config file (or use our migration tool):

{
  "jsPlugins": ["eslint-plugin-testing-library"],
  "rules": {
    "testing-library/no-render-in-lifecycle": "error"
  }
}

Lint your project:

pnpm run lint

Migrating from ESLint ​

Most projects should find that migrating from ESLint is straightforward.

The simplest route is via the @oxlint/migrate tool.

npx @oxlint/migrate eslint.config.js

Or ask your coding agent to do it for you with the migrate-oxlint skill.

See the migration guide for more details.

ESLint rules ​

Oxlint already natively implements most of ESLint's built-in rules, rewritten in Rust, but not all rules are implemented yet.

To bridge this gap, we provide oxlint-plugin-eslint, which contains all ESLint's built-in rules packaged as an Oxlint JS plugin.

This unlocks rules like no-restricted-syntax which are not yet implemented natively in Oxlint.

{
  "jsPlugins": ["oxlint-plugin-eslint"],
  "rules": {
    // Note: "eslint-js" not "eslint"
    "eslint-js/no-restricted-syntax": [
      "error",
      {
        "selector": "ThrowStatement > CallExpression[callee.name=/Error$/]",
        "message": "Use `new` keyword when throwing an `Error`.",
      },
    ],
  },
}

Oxlint also implements a subset of rules from plugins like eslint-plugin-jsdoc natively. For rules which aren't implemented in Oxlint itself, you can use the eslint-plugin-jsdoc package directly. This is the recommended pattern:

{
  "jsPlugins": [
    // Set up an alias for the plugin "jsdoc-js"
    { "name": "jsdoc-js", "specifier": "eslint-plugin-jsdoc" },
  ],
  "rules": {
    // Use the alias to refer to rules from the plugin
    "jsdoc-js/check-examples": "error",
    "jsdoc-js/require-description": "error",
    // Use plain "jsdoc" for rules which Oxlint implements natively
    "jsdoc/require-property-name": "error",
    "jsdoc/require-property-description": "error",
  },
}

Performance ​

Since the first technical preview, we have "Rustified" large chunks of the code powering JS plugins, which has delivered significant performance gains. In particular, plugins which rely on tokens APIs (e.g. ESLint Stylistic) are up to 5 times faster than before.

As a benchmark, we migrated Node.js's repo from ESLint to Oxlint. Node.js is a large project utilizing many custom lint rules, as well as several heavy ESLint plugins (98 JS lint rules in total).

git checkout bench-eslint
npm ci
hyperfine -i --warmup 1 --runs 5 "node --run eslint"

git checkout bench-oxlint
npm ci
hyperfine -i --warmup 1 --runs 5 "node --run oxlint"

Projects which currently use TypeScript-ESLint or eslint-plugin-import will likely see much larger performance gains. One user in our Discord reported a 16x speed-up linting their company's 2 million line codebase when switching from ESLint to Oxlint, with heavy usage of JS plugins. Projects which use JS plugins more sparingly have reported speed gains of up to 100x.

Future perf improvements ​

This is just the beginning!

While Oxlint with JS plugins is already significantly faster than ESLint, we have many more optimizations in the pipeline.

The key to Oxlint's JS plugin performance is a new, highly optimized, low-level mechanism for communicating between Rust and JS, which we call "raw transfer".

The Rust/JS boundary has always been the fundamental problem for native tooling supporting JS plugins. Native code is fast, but the cost of sending data back and forth between Rust and JS can be so high that it offsets that gain, resulting in mediocre performance overall.

Raw transfer reduces the cost of moving data between Rust and JS almost to zero, finally enabling native code and JS plugins to work effectively in tandem.

The first iteration of raw transfer is already at work under the hood of Oxlint, but we've only just begun leveraging what it can do. As we continue this work, we expect to see a further step-change in performance, bringing JS plugins close to native Rust performance.

If you're interested in the details, Oxc core team member @overlookmotel gave a talk at ViteConf 2025 on this subject.

In short: Oxlint is already the fastest JS/TS linter in existence. It's going to get a lot faster.

Perf tip 1: Use a formatter ​

We strongly recommend moving from using the linter for code formatting, to using Oxfmt (or your preferred formatter), if you can.

Oxfmt is 30x faster than Prettier, and will also dramatically reduce linting time vs linter plugins like ESLint Stylistic.

Oxlint and Oxfmt make a very strong team!

Perf tip 2: Choose plugins wisely ​

Contrary to what many believe, it is perfectly possible to write extremely performant JavaScript code. Oxlint is not fast just because it's written in Rust - it's also carefully designed with performance in mind.

The code of JS plugins themselves is not under Oxlint's control. To get good performance out of Oxlint overall requires the JS plugins you select to perform well too.

If a plugin uses inefficient algorithms or performs a lot of filesystem operations, it'll be slow in ESLint, and slow in Oxlint too. What Oxlint can do is provide a lightning-fast parser and performant APIs for plugins to interface with, but it can't magically make slow JS code faster.

We will in future provide a utility to diagnose which plugins/rules are the performance bottlenecks in your project, if you find that linting is not as fast as you'd like.

Creating custom plugins ​

If your project has specific needs, it's simple to create a custom JS plugin for Oxlint.

Please see the JS plugin guide.

FAQ ​

Can Oxlint run ESLint plugins? Yes. Most plugins work without modification.

Is Oxlint faster than ESLint? Yes. Benchmarks typically show 4x–100x speedups.

Can I migrate gradually? Yes. You can run Oxlint alongside ESLint.

Thanks to ​

Bringing JS plugins up to this milestone has been the work of many hands. In particular, we'd like to thank:

• @Sysix for tireless work on the language server integration.
• @lilnasy for building out many of the APIs.

Join the community ​

We'd love to hear your feedback on Oxlint JS plugins, and are excited to see how it helps improve your development workflow.

Connect with us:

• Discord: Join our community server for real-time discussions
• GitHub: Share feedback on GitHub Discussions
• Issues: Report oxlint bugs to oxc.