Bun Lint: 26x Faster ESLint-Compatible Linter with 1,021 Built-in Rules

Key Takeaways

• bun lint is Bun’s built-in linter, announced as 26x faster than ESLint on average with 1,021 native rules and near-perfect test compatibility.
• It reads existing ESLint (eslint.config.js, .eslintrc) and oxlint (.oxlintrc.json) configurations with no changes required in most projects.
• Type-aware rules run without the typescript package by leveraging the same Rust-ported parser and type checker used by bun check.
• ESLint plugins are supported (both npm packages and local rules), while core rules from unicorn, react, import, jest, vitest, jsx-a11y and others ship natively.
• Benchmarks show dramatic wins on real codebases (shadcn/ui 43x, vscode 26x) with 99.6% ESLint and 99.8% oxlint test pass rates, plus lower memory use than oxlint.

What Is bun lint?

bun lint is the native linter that ships with the Bun JavaScript/TypeScript toolkit. Analysis of the October 2026 announcement and official documentation shows it targets the exact pain points that have kept teams on ESLint for a decade: configuration lock-in, plugin ecosystems, and type-aware checks.

Unlike a pure speed-focused tool that forces a config rewrite, bun lint is designed as a drop-in replacement. It understands ESLint flat configs, legacy configs, and oxlint configs. The command surface mirrors ESLint closely (--fix, --max-warnings, path globs, etc.), so most projects only change the script entry from eslint to bun lint.

Under the hood it is powered by a TypeScript parser and type checker ported to Rust, plus the same AST used by bun check. This shared foundation eliminates duplicate parsing work and enables type-aware rules without pulling in the full TypeScript package at lint time.

Performance Benchmarks and Real-World Numbers

Benchmarks published with the announcement show average 26x speedups versus ESLint when both tools run the same project configs and plugins:

• shadcn/ui: 2.1 s vs 90.4 s (43x)
• chakra-ui: 0.59 s vs 22.6 s (38x)
• vscode: 15.8 s vs 404 s (26x) — 9,823 of 9,826 messages identical
• mastodon: 6.6 s vs 100 s (15x)
• playwright: 4.9 s vs 53.4 s (11x)

Additional claims include 2x faster than oxlint with 3x less memory, 99.6% of ESLint’s tests passing, and 99.8% of oxlint’s tests passing. These figures come from production-scale repositories rather than synthetic micro-benchmarks, which makes the results more relevant for teams evaluating a switch.

The speed advantage stems from three design choices: a Rust implementation, multi-core utilization by default, and a single high-quality parser that is already warm from other Bun operations. Community feedback on similar Rust linters (oxlint, Biome) has long shown that the biggest gains appear on large monorepos and CI runs; bun lint appears to follow the same pattern while adding ESLint plugin compatibility.

Rule Coverage and Categories

Documentation lists 1,021 built-in rules. Rough breakdown from the public rules page includes:

• ~218 ESLint core rules
• ~137 typescript-eslint rules (62 of which are type-aware)
• Substantial ports from oxlint (unicorn, jest, vitest, jsx-a11y, next, promise)
• React, react-hooks, import, and additional categories

Default behavior (no config file) enables ESLint recommended rules, typescript-eslint recommended rules on .ts/.tsx files, key React rules (rules-of-hooks, exhaustive-deps, jsx-key) when React is detected, and a small set of test-specific rules for files that import from bun:test.

Rules can be toggled individually, given options, or activated by category (correctness, suspicious, pedantic, perf, style, restriction, nursery) inside bunfig.toml.

Configuration: bunfig.toml, ESLint, and oxlint

The simplest path is zero-config: run bun lint and it applies the recommended sets above. For customization, three options exist:

1. bunfig.toml (recommended for Bun-native projects)
2. Existing eslint.config.js / .eslintrc
3. Existing .oxlintrc.json or oxlint.config.ts

Example bunfig.toml:

[lint]
typeAware = true
ignorePatterns = ["vendor/", "**/*.gen.ts"]
plugins = ["eslint-plugin-perfectionist"]

[lint.rules]
"no-console" = "warn"
"eqeqeq" = ["error", "smart"]
"@typescript-eslint/no-explicit-any" = "off"
"perfectionist/sort-imports" = "error"

[[lint.overrides]]
files = ["*.test.ts", "scripts/**"]
rules = { "no-console" = "off" }

Run bun lint --init to generate the [lint] section. Unknown rule names produce an immediate error with a suggestion rather than a silent no-op. Overrides, ignore patterns, and plugin loading all work as expected.

When both an ESLint and an oxlint config exist, bun lint prefers the oxlint config by default; --flavor=eslint or --config selects the other.

Plugin Support and Extensibility

Large codebases frequently rely on custom or third-party rules. bun lint loads standard ESLint plugins from npm or local paths without requiring the eslint package itself. Built-in plugins (react, import, unicorn, etc.) do not need to be listed; their rules are already available.

Local plugin example structure follows the classic ESLint plugin API (meta.name, rules object). The prefix used in rule names is the plugin’s meta.name (or an explicit name override). --doctor reports which rules run natively versus which fall back to JavaScript plugin execution.

This hybrid model is the key differentiator versus pure Rust linters that historically lacked plugin support. Teams can keep their existing custom rules while gaining native speed on the majority of checks.

Type-Aware Linting

Type-aware rules (the 62+ rules that need type information) are powered by the same type checker used by bun check. Enable them globally with:

[lint]
typeAware = true

or enable individual rules. Because the parser and checker are shared and already optimized for Bun, the incremental cost is lower than spinning up a separate TypeScript language service. Still, type-aware mode is slower than pure syntactic linting; projects with very large type graphs should measure CI impact before making it the default.

Migration Path and Practical Tips

Most migrations reduce to a one-line script change:

{
  "scripts": {
    "lint": "bun lint --max-warnings 0"
  }
}

Practical tips and edge cases:

• Existing eslint-disable and oxlint-disable comments continue to work.
• Auto-fix (bun lint --fix) is available; fixes that would produce unparseable output are skipped and reported.
• Unknown rules do not halt the entire run (unlike some oxlint versions); the process finishes other rules then exits with code 2. Use --allow-unsupported to downgrade this to a warning.
• Output is sorted by file and line for stable CI diffs.
• Syntax error messages can differ slightly from ESLint or oxlint; control-flow rules deliberately follow ESLint behavior where the tools diverge.
• --lsp is not supported.
• On projects that currently run oxlint && eslint, switch to bun lint --flavor=oxlint && bun lint --flavor=eslint if both rule sets are still required.
• Measure type-aware mode separately; the default non-type-aware path already delivers the majority of the speed gain.

Common pitfalls include assuming every obscure ESLint plugin will run at native speed (only selected plugins are fully native) and forgetting that type-aware checks add latency. Running bun lint --doctor quickly surfaces which rules are native versus JavaScript.

Why bun lint Matters in 2026

ESLint remains the ecosystem standard, but its JavaScript implementation and plugin model create measurable CI and developer-experience costs on large codebases. oxlint proved Rust could deliver 50–100x speedups, yet plugin and type-aware gaps kept many teams from a full switch. bun lint closes those gaps while remaining inside the Bun binary that teams already use for runtime, test, and package management.

The combination of drop-in config compatibility, 1,021 rules, plugin support, and measured 11–43x speedups on real repositories positions it as the strongest candidate yet for teams that want ESLint semantics without ESLint’s runtime cost.

Conclusion

bun lint delivers a practical, high-compatibility path to dramatically faster linting without forcing a rewrite of configurations or abandonment of custom plugins. Benchmarks indicate consistent multi-fold improvements on production codebases, while the shared Rust parser and type checker keep type-aware rules accessible.

Upgrade to a recent Bun release, run bun lint on your existing project, and compare wall-clock time and result parity against your current ESLint or oxlint setup. Most teams can adopt it in minutes and immediately reclaim CI minutes and local feedback latency.