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

Discover bun lint: 26x faster than ESLint, 1,021 rules, full ESLint/oxlint config compatibility, plugin support, and type-aware linting built into Bun.

Canonical URL: https://aiidelist.com/blog/bun-lint

Language: en

Published: 2026-10-15

Updated: 2026-10-15

## 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`:

```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:

```toml
[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:

```json
{
  "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.