Bun’s Twitter account announced bun lint this week: an ESLint-compatible linter built into Bun. The announcement claims 26x the speed of ESLint, 1,021 builtin rules, and it reads existing eslint and oxlint configs. There is also bun fmt, which reads Prettier and oxfmt configs. I saw it via a Boris Cherny retweet, which is how I hear about most Bun features.
My interest was practical. My blog runs ESLint with typescript-eslint recommended plus eslint-plugin-astro, and I wanted to know whether Bun’s native linter matches it on a real config instead of a toy repo.
Getting the canary without touching stable
bun lint is still not in stable Bun. Stable is now 1.4.4 (Homebrew, released 22 October 2026), up from 1.4.3 when I first tried this, and that release already ships bun check and bun fmt. The linter is the only builtin left that needs a canary build, so the canary stays. It is now 1.4.4-canary.1+2596ac5d3, updated 8 November 2026. I downloaded the canary release zip from oven-sh/bun into ~/.bun-canary/bin/bun and added a bunc wrapper:
#!/bin/sh# bun canary — plain `bun` stays on the Homebrew stable buildexec "$HOME/.bun-canary/bin/bun" "$@"Plain bun stays on 1.4.4. bunc is the canary. Nothing conflicts. One quirk: --version prints 1.4.4 for both, so tell the builds apart with --revision. Stable bun lint still has no builtin at all, it answers error: Script not found "lint".
The benchmark: identical results
My eslint.config.js combines tseslint.configs.recommended, eslintPluginAstro.configs.recommended, browser and node globals, a no-console rule, and some ignore paths. bunc lint --doctor reported:
25 rules run natively 9 rules run in JavaScript eslint-plugin-astro 9Bun runs what it implements natively and executes the Astro plugin’s rules in JavaScript instead of ignoring them. Then the run itself:
$ bunc lint✓ No problems in 120 files [3.40s]ESLint on the same repo: no problems, 5.16s. Identical findings. On a repo this size the speedup is modest (the 26x figure comes from huge codebases like VS Code), but parity is what I wanted to see.
Re-ran on 8 November with the new canary, three weeks later. The repo has grown since, and the doctor output is unchanged: 25 rules native, 9 in JavaScript. The run:
$ bunc lint --no-script✓ No problems in 140 files [4.66s]ESLint on the same tree still reports no problems. Parity held.
One gotcha, now fixed: my package.json has a lint script, and in the first canary I tried, the script shadowed the builtin, so bunc lint ran eslint . instead of the linter. The docs said bun lint --no-script always runs the linter, but that canary did not recognize the flag yet. It does now.
If bun lint looks suspiciously like plain ESLint, check your package.json first. A script named lint shadows the builtin, so pass --no-script to force the builtin.
Where that leaves me
bun lint itself is legitimate, and the repo already lints with it through canary. Stable 1.4.4 took bun check and bun fmt in, so the canary now exists for the linter alone. Once bun lint reaches stable Bun, the canary goes away, since the migration is nearly trivial as it reads the existing config.