Oxc for VS Code: lint and format JavaScript 50× faster than ESLint
The Oxc VS Code extension brings oxlint and oxfmt — both Rust-powered, both multi-threaded — into your editor. On a real 5,360-file TypeScript monorepo, oxlint finishes in 1.3s vs ESLint's 2m 27s. Here's how to install it, enable format-on-save, and migrate from ESLint without breaking CI.
Your linter shouldn't take two and a half minutes. For most mid-size JavaScript or TypeScript projects running ESLint with type-aware rules, it does. 3 — Reddit|[https://www.[reddit.com/r/webdev/comments/1rkmt1k/migrated_from_eslint_prettier_to_oxlint_oxfmt/]]](https://www.reddit.com/r/webdev/comments/1rkmt1k/migrated_from_eslint_prettier_to_oxlint_oxfmt/]])](https://reddit.com/r/webdev/comments/1rkmt1k/migrated_from_eslint_prettier_to_oxlint_oxfmt/]]](https://www.reddit.com/r/webdev/comments/1rkmt1k/migrated_from_eslint_prettier_to_oxlint_oxfmt/]]))
The Oxc VS Code extension connects VS Code to oxlint and oxfmt — both written in Rust, both multi-threaded, both part of the Oxidation Compiler project that VoidZero is building as a unified JavaScript toolchain. Install the extension and you get inline lint squiggles and on-save formatting in your editor without touching your CI config.
What oxlint and oxfmt actually do
oxlint is a JavaScript/TypeScript linter. It ships with 650+ built-in rules covering ESLint core, TypeScript, React, Jest, and
jsx-a11y. By default, 107 rules are enabled out of the box — no config file needed to start catching real issues. 1oxfmt is the companion formatter, meant to replace Prettier for JS/TS files. Like oxlint, it's multi-threaded and does not require configuration to run.
The extension bundles both binaries. When you open a
.js, .ts, .jsx, or .tsx file in VS Code, oxlint runs in the background and surfaces diagnostics; if you set oxc as your default formatter, oxfmt formats on save.The speed gap
Real-world numbers from a developer who migrated an NX monorepo (M3 MacBook Pro, 5,360 files): 3 — Reddit|[https://www.[reddit.com/r/webdev/comments/1rkmt1k/migrated_from_eslint_prettier_to_oxlint_oxfmt/]]](https://www.reddit.com/r/webdev/comments/1rkmt1k/migrated_from_eslint_prettier_to_oxlint_oxfmt/]])](https://reddit.com/r/webdev/comments/1rkmt1k/migrated_from_eslint_prettier_to_oxlint_oxfmt/]]](https://www.reddit.com/r/webdev/comments/1rkmt1k/migrated_from_eslint_prettier_to_oxlint_oxfmt/]]))
| Tool | Time | Notes |
|---|---|---|
| ESLint | ~2m 27s | Single-threaded, type-aware rules |
| oxlint | ~1.3s | 5,360 files, 134 rules, 11 threads |
| Prettier | ~13.9s | 6,111 files |
| oxfmt | ~2.1s | 6,111 files, 11 threads |
That's 113× faster for linting and 6.5× faster for formatting. Oxlint's own benchmark repo puts the headline figure at 50–100× on the VS Code codebase using standard rules. 2 The difference comes from Rust's execution speed plus native thread-per-core parallelism — ESLint processes one file at a time.
The speed matters for editor UX. ESLint extensions often introduce a noticeable lag before squiggles appear; oxlint's results show up near-instantly on every keystroke save.
Install
Search for Oxc in the VS Code Extensions panel (
Ctrl+Shift+X / Cmd+Shift+X), or run:ext install oxc.oxc-vscodeThe identifier is
oxc.oxc-vscode. The extension is also available on Open VSX for VS Codium and other compatible editors.Enable oxfmt as your default formatter
After installing, add this to your
settings.json to enable format-on-save:{
"[javascript]": {
"editor.defaultFormatter": "oxc.oxc-vscode",
"editor.formatOnSave": true
},
"[typescript]": {
"editor.defaultFormatter": "oxc.oxc-vscode",
"editor.formatOnSave": true
},
"[javascriptreact]": {
"editor.defaultFormatter": "oxc.oxc-vscode"
},
"[typereactscript]": {
"editor.defaultFormatter": "oxc.oxc-vscode"
}
}oxfmt's formatting style is intentionally close to Prettier. Most codebases need zero extra configuration.
Add type-aware linting (optional)
Standard oxlint rules run without a TypeScript server — that's most of the speed advantage. If you also want type-aware rules (the equivalent of
typescript-eslint's recommended-type-checked), install the separate oxlint-tsgolint package:npm install --save-dev oxlint-tsgolintThen enable it in your VS Code settings:
{
"oxc.typeAware": true
}Type-aware mode uses
tsgo (the Go-based TypeScript port) instead of the full tsc pipeline. Even with type checking on, oxlint benchmarks at 20–40× faster than ESLint + typescript-eslint. 1Migrating from ESLint without breaking CI
oxlint can run alongside ESLint during a transition. The automated migration tool handles most of the conversion:
# For ESLint v9 flat config projects
npx @oxlint/migrate
# For projects that depend heavily on ESLint plugins
npx @oxlint/migrate --js-plugins
# For type-aware rules
npx @oxlint/migrate --type-awareRules that oxlint doesn't support yet get flagged — you keep running ESLint only for those. Once coverage satisfies your team, drop ESLint entirely. 1
Limitations worth knowing
- ESLint plugin ecosystem: oxlint supports most ESLint v9 API surface, but "experimental" is the honest label for plugin compat. Complex in-house ESLint plugins may need adaptation.
- oxfmt is still young: Prettier has years of edge-case handling in its AST formatting logic. oxfmt produces cleaner diffs for most code, but very unusual formatting patterns may differ.
- 650+ rules, not unlimited: ESLint's full ecosystem has thousands of community rules. oxlint prioritizes correctness and coverage of the most commonly-used rule sets first.
Install link: Oxc on VS Code Marketplace · Identifier:
oxc.oxc-vscodeReferences
- 1
- 2
- 31|Migrated from ESLint + Prettier to Oxlint + Oxfmt [Benchmarks
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.