{"id":364,"date":"2026-06-24T13:01:21","date_gmt":"2026-06-24T13:01:21","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/biome-vs-eslint-2026-the-linter-switch-i-kept-putting-off\/"},"modified":"2026-06-24T13:01:21","modified_gmt":"2026-06-24T13:01:21","slug":"biome-vs-eslint-2026-the-linter-switch-i-kept-putting-off","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/biome-vs-eslint-2026-the-linter-switch-i-kept-putting-off\/","title":{"rendered":"Biome vs ESLint in 2026: The Linter Switch I Kept Putting Off"},"content":{"rendered":"

I’d been promising myself to “look at Biome this weekend” for about ten weekends in a row. Last month I finally did it on a real Next.js project and the migration took less than an hour. ESLint and Prettier had spent four years quietly growing in my repos, and I kept telling myself the config was fine, the speed was fine, everything was fine.<\/p>\n

Reader, it was not fine.<\/p>\n

This is the honest write-up I wanted to read before I did the switch. What broke, what didn’t, the rough numbers from my own machine, and the parts where I’m still keeping ESLint around for one specific reason. If you’re a TypeScript developer who’s been hearing “just switch to Biome” for months and waving it away, this one’s for me a year ago.<\/p>\n

Why I held out on ESLint for so long<\/h2>\n

ESLint is the lingua franca. That’s the honest reason. Every plugin I cared about, eslint-plugin-react<\/code>, eslint-plugin-import<\/code>, eslint-plugin-jsx-a11y<\/code>, the TypeScript-ESLint stack, assumed ESLint’s rule API. The big rewrites in ESLint 9 with flat config<\/a> actually fixed my biggest complaint, which was the legacy .eslintrc.json<\/code> cascade mess. Once I migrated to flat config, the urge to look elsewhere quietly dropped to zero.<\/p>\n

What changed my mind was a new TypeScript monorepo at work where I had three packages and zero patience. The lint step was running for thirty-six seconds on my laptop before a single test had executed. The CI pipeline spent more time linting than running unit tests. I’d had enough.<\/p>\n

I’d also been burned by Prettier-vs-ESLint config wars often enough that “one tool that does both, and they don’t fight” stopped sounding like a marketing pitch and started sounding like sanity.<\/p>\n

What Biome actually is, in two sentences<\/h2>\n

Biome is a Rust-based toolchain that bundles a linter and a formatter into one binary. It speaks JavaScript, TypeScript, JSX, JSON, and CSS, and as of Biome v2<\/a>, it supports type-aware lint rules without needing the TypeScript service running in a separate process.<\/p>\n

That last part is the real story. The thing that always made ESLint slow on a TypeScript project was spinning up the TypeScript parser and running type-aware analyses against tsc<\/code>. Biome’s type-aware mode runs its own inference inside the same Rust process. Same checks, much less ceremony.<\/p>\n

My install and config, before and after<\/h2>\n

Before, in the monorepo root, the dev dependencies were already getting absurd:<\/p>\n

{\n  "devDependencies": {\n    "eslint": "^9.10.0",\n    "@eslint\/js": "^9.10.0",\n    "typescript-eslint": "^8.6.0",\n    "eslint-plugin-react": "^7.36.1",\n    "eslint-plugin-react-hooks": "^4.6.2",\n    "eslint-plugin-jsx-a11y": "^6.10.0",\n    "eslint-plugin-import": "^2.30.0",\n    "prettier": "^3.3.3",\n    "eslint-config-prettier": "^9.1.0",\n    "eslint-plugin-prettier": "^5.2.1"\n  }\n}\n<\/code><\/pre>\n
Ten packages. Several with their own peer-dependency drama on every minor bump. Add to that a real eslint.config.mjs<\/code>:<\/p>\n
import js from "@eslint\/js";\nimport tseslint from "typescript-eslint";\nimport reactHooks from "eslint-plugin-react-hooks";\nimport jsxA11y from "eslint-plugin-jsx-a11y";\nimport importPlugin from "eslint-plugin-import";\nimport prettier from "eslint-config-prettier";\n\nexport default tseslint.config(\n  js.configs.recommended,\n  ...tseslint.configs.recommendedTypeChecked,\n  {\n    plugins: {\n      "react-hooks": reactHooks,\n      "jsx-a11y": jsxA11y,\n      import: importPlugin,\n    },\n    languageOptions: {\n      parserOptions: {\n        project: [".\/tsconfig.json", ".\/packages\/*\/tsconfig.json"],\n      },\n    },\n    rules: {\n      "react-hooks\/rules-of-hooks": "error",\n      "react-hooks\/exhaustive-deps": "warn",\n      "import\/order": ["warn", { "newlines-between": "always" }],\n    },\n  },\n  prettier,\n);\n<\/code><\/pre>\n
And a .prettierrc.json<\/code> because of course there is one of those too. And a .eslintignore<\/code>. And a .prettierignore<\/code>.<\/p>\n
After, the entire setup fits in one file:<\/p>\n
{\n  "$schema": "https:\/\/biomejs.dev\/schemas\/2.0.0\/schema.json",\n  "vcs": { "enabled": true, "clientKind": "git", "useIgnoreFile": true },\n  "files": { "ignoreUnknown": true },\n  "formatter": { "enabled": true, "indentStyle": "space", "indentWidth": 2 },\n  "linter": {\n    "enabled": true,\n    "rules": {\n      "recommended": true,\n      "correctness": { "useExhaustiveDependencies": "warn" },\n      "style": { "useImportType": "error" }\n    }\n  },\n  "javascript": { "formatter": { "quoteStyle": "double", "trailingCommas": "all" } }\n}\n<\/code><\/pre>\n
One file. One devDependency, @biomejs\/biome<\/code>. That’s it.<\/p>\n
The migration itself was two commands:<\/p>\n
npx @biomejs\/biome migrate eslint --write\nnpx @biomejs\/biome migrate prettier --write\n<\/code><\/pre>\n
The Biome CLI reads your old configs and ports what it can. The bits it can’t port it tells you about, and ninety percent of those, for me, were rules I’d added in a panic at 2 AM and never actually needed.<\/p>\n
Where Biome was faster, and by how much<\/h2>\n
Numbers from my monorepo: three packages, around 38,000 lines of TypeScript, MacBook Pro M3, warm cache, three runs averaged.<\/p>\n\n\n\n\n\n\n\n
Tool<\/th>\nLint only<\/th>\nFormat only<\/th>\nLint + format<\/th>\n<\/tr>\n<\/thead>\n
ESLint 9 + Prettier 3<\/td>\n36.4 s<\/td>\n8.1 s<\/td>\n44.1 s<\/td>\n<\/tr>\n
Biome 2 (no type-aware)<\/td>\n1.2 s<\/td>\n0.6 s<\/td>\n1.5 s<\/td>\n<\/tr>\n
Biome 2 (type-aware on)<\/td>\n4.8 s<\/td>\n0.6 s<\/td>\n5.1 s<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The non-type-aware lint went from thirty-six seconds to a second and a half. The type-aware run, the one I actually care about for CI, dropped from forty-four seconds to five.<\/p>\n
In CI on GitHub-hosted runners, the wall-clock for the lint job dropped from one minute fourteen seconds to seven seconds. The whole pipeline shaved off about a minute, mostly because I’d been splitting lint and format into two jobs to avoid blocking PRs. With Biome I went back to one job and stopped thinking about it.<\/p>\n
For tooling that touches every file on every commit, that’s the kind of speed-up that changes what you’ll do in a pre-commit hook. I went back and added a Biome check to a project where I’d given up on lint hooks two years ago because they were too slow to keep. Same way I felt about pnpm replacing npm<\/a> when my CI cache finally stopped feeling like a punishment.<\/p>\n
Where Biome still trails ESLint<\/h2>\n
I want to be fair. The honest gap as of June 2026:<\/p>\n
    \n
  1. Plugin ecosystem.<\/em> ESLint’s catalogue of community rules is enormous. Biome has been catching up rule-by-rule and hit feature parity on the rules I actually used. But if you depend on a niche plugin, some company-internal rule pack, some deep accessibility rules, check first. Biome’s useValidAriaProps<\/code> and friends cover most of what I’d otherwise lose.<\/li>\n
  2. Vue and Svelte.<\/em> Biome’s first-class support is JS\/TS\/JSX\/JSON\/CSS. Vue SFC support is in beta. If you’re a Svelte shop, you’re not the target audience yet.<\/li>\n
  3. Custom rules.<\/em> Writing a custom ESLint rule is a fifteen-minute job. Biome’s plugin system works but is still maturing. I had one internal rule (a no-process.env.MY_FLAG<\/code> check) and I left ESLint installed just to run that one rule. Took me five minutes of guilt before I admitted that was fine.<\/li>\n
  4. Editor integration.<\/em> The Biome VS Code extension works well, but if you’d been deep in the ESLint extension’s settings, you’ll spend an evening reconfiguring. The official Biome VS Code extension<\/a> is what you want, not any third-party variant.<\/li>\n<\/ol>\n
    I read ESLint’s own blog<\/a> reflecting on the rise of Rust-based competitors, and it’s a pretty grown-up response. They’re not trying to out-Rust Biome. They’re leaning into the plugin ecosystem they already have, which is the right call.<\/p>\n
    My current setup, end of June 2026<\/h2>\n
    For a fresh Next.js or Vite project, this is what I run:<\/p>\n