biome or keep eslint+prettier when lint takes 4m12s on 180k lines Solved

Ran this migration on a comparable repo (~150k lines). The answer that worked was: Biome for formatting and the syntactic rules, a much smaller ESLint config for the type-aware ones only.

What that looks like in practice:

• Biome replaces Prettier entirely. Format check went from 40s to about 3s. This part is free and you should do it regardless of what you decide about linting.
• Biome takes over the several hundred rules that need no type information. Our full Biome check is around 9 seconds on the whole repo.
• ESLint stays, but with parserOptions.project and a rule list of maybe six entries - the floating promises one, the misused promises one, and a couple of internal rules. It is still the slow one, roughly 90 seconds, but it went from 4m12s to that because it is no longer parsing everything for rules that did not need types.

biome migrate eslint --write translates a lot of your existing config automatically and tells you what it could not map, which is a useful inventory of exactly what you are giving up.

Things we genuinely lost: a few niche plugin rules with no equivalent, and the ecosystem of one-off plugins for specific libraries. Nobody has missed them in eight months.

Before you migrate anything, find out where the 4 minutes goes, because you might be fixing the wrong problem.

TIMING=1 eslint . --ext .ts,.tsx

prints the ten slowest rules with percentages. If one type-aware rule is 60% of the time, you have a targeted fix rather than a migration.

Then check the cheap wins:

• --cache with the cache file in a location Turbo does not blow away between runs.
• lint as a per-package turbo task so it caches per package and unchanged packages cost nothing. If you are running one lint task at the repo root you are re-linting 11 packages to check a change in one.
• make sure parserOptions.project is not pointed at a tsconfig that includes test fixtures or generated files.

We got from 3m40s to about 25s without changing tools, purely from per-package caching. Then we moved to Biome anyway, but at least we did it because we wanted to and not under duress.

Concrete list of what you cannot currently get without type information, so you can decide whether you care:

• floating promises / unhandled rejections
• promise passed where a void callback is expected
• unsafe any propagation rules
• anything that needs to know whether a type is nullable

Everything else you probably use - unused vars, import ordering, hook dependency arrays, accessibility rules on JSX - is syntactic and has an equivalent.

My honest read: the floating promise rule is worth keeping ESLint around for on its own. It catches real production bugs, not style opinions.

One thing to decide up front is whether lint blocks the merge or just annotates it. We moved the slow type-aware pass to a scheduled run against main and kept only the fast checks on PRs. Fewer people waiting on a queue, and the rules still catch things within a few hours.

4m12s of linting on every push is a lot of collective staring at a spinner. Whatever you pick, that maths alone justifies an afternoon.