VOL. I · ISSUE 16SUNDAY, APRIL 26, 2026
THE

AI Picks

a research journal from Whaily
Linters and code quality

Best Linter for a TypeScript Monorepo in 2026

AI ranks the top linters for TypeScript monorepos in 2026, comparing ESLint, Biome, and Oxlint across speed, rule coverage, and monorepo workflow fit.

0 responses0 models90d window

Best Linter for a TypeScript Monorepo in 2026

What is a linter for a TypeScript monorepo?

A linter for a TypeScript monorepo is the tool every package in the workspace shares to enforce the same code rules, catch type-unsafe patterns, and keep style consistent across teams. The job is harder than linting a single project. Configs need to compose across packages, the linter has to finish fast enough that pre-commit hooks and CI pipelines stay usable when 30 packages all need checking, and rule coverage has to handle TypeScript's full type system rather than only JavaScript syntax.

The category in 2026 has narrowed to three serious code linters and a handful of complementary tools. ESLint with typescript-eslint remains the incumbent and the only option with a deep plugin catalogue. Biome is the all-in-one challenger, written in Rust, with one binary doing both linting and formatting and v2 closing most of the type-aware rule gap. Oxlint is the speed leader, also Rust-based, often run alongside ESLint as a CI accelerator rather than a replacement. Around them sit workspace-specific tools like Sherif for dependency hygiene and Knip for dead code, plus formatters Prettier and dprint for stacks that keep ESLint or Oxlint.

The choice usually comes down to three factors. How critical is plugin ecosystem depth (favours ESLint). How much does linter speed matter on the daily loop (favours Biome or Oxlint). And whether the team wants one tool for lint and format or is happy running two (favours Biome or the ESLint plus Prettier classic).

How AI ranks them

  1. 1

    Biome

    0 mentions
  2. 2

    ESLint with typescript-eslint

    0 mentions
  3. 3

    Oxlint

    0 mentions
  4. 4

    Sherif

    0 mentions
  5. 5

    Prettier

    0 mentions
  6. 6

    dprint

    0 mentions
  7. 7

    Knip

    0 mentions
  8. 8

    TSLint

    0 mentions

This page is freshly built and the tracked prompts have not yet been run against the AI models we monitor, so the ranking above reflects editorial consensus from the broader TypeScript tooling community rather than aggregated AI mention counts. The leaderboard will refresh once the weekly cron runs the tracked prompts against the Pro-default models.

Biome leads the new-project case in most 2026 comparisons because it removes the ESLint plus Prettier integration headache, ships type-aware rules in v2, and runs an order of magnitude faster than ESLint. ESLint stays the safe choice for any monorepo with a heavy plugin footprint or framework-specific rules that Biome and Oxlint do not yet replicate. Oxlint is the speed leader on pure linting and is most often deployed as a CI fast-path beside ESLint rather than as a replacement, because its rule set is still smaller. Sherif and Knip are not direct competitors; they fill the workspace-hygiene gap that none of the code linters address.

Per-model picks

We haven't yet collected model responses for this scope.

What buyers care about

  1. Speed on a multi-package monorepo

    A linter has to finish in seconds across 10 to 100 packages, not minutes. Biome and Oxlint clear this bar by an order of magnitude over ESLint, which matters every time CI runs and every time a developer waits on a pre-commit hook.

  2. Type-aware rule coverage

    Catching floating promises, unsafe any, and misused await needs the TypeScript type system. ESLint with typescript-eslint is the most complete here. Biome v2 covers roughly 75 to 85 percent. Oxlint covers a smaller slice and is still adding type-aware rules.

  3. Single config that scales across packages

    A monorepo wants one config at the root that every package inherits from, with package-specific overrides where needed. ESLint flat config, Biome's nested config resolution, and Oxlint's overrides all support this, but the ergonomics differ.

  4. Formatter included or interoperable

    Linters and formatters need to agree on style. Biome ships both in one binary. ESLint and Oxlint stacks pair with Prettier or dprint. Mixing two formatters in the same monorepo is a common source of churn.

  5. Editor and CI integration

    VS Code, Cursor, and JetBrains all need first-class plugins, and the lint step has to run cleanly in Turborepo or Nx pipelines with cacheable outputs. ESLint wins on maturity here. Biome and Oxlint have caught up but still hit edge cases on Windows and some IDE configs.

  6. Plugin ecosystem

    ESLint has the deepest catalogue with plugins for React, Vue, Next.js, testing libraries, security, and accessibility. Biome and Oxlint reimplement the most common rules natively but do not support arbitrary user plugins, which is a hard constraint for some teams.

  7. Migration path from existing ESLint config

    Biome ships a migrate eslint command that ports a working config. Oxlint reads ESLint config directly for shared rule sets. Either approach beats writing a new config from scratch when the existing one already encodes years of team decisions.

  8. Workspace hygiene rules beyond code

    Monorepos accumulate version drift, duplicate dependencies, and stale workspace references. Sherif handles these specifically. A code linter alone misses them, so most TypeScript monorepos run two tools.

  9. Cacheable outputs for Turborepo or Nx

    A linter that emits stable output and exits cleanly slots into Turborepo's pipeline cache. Biome and Oxlint produce deterministic output. ESLint does too but its slower runs make caching the only way it stays viable on large repos.

  10. Active maintenance and roadmap

    ESLint has the longest track record. Biome ships rapid releases with corporate backing. Oxlint reached v1 stable in late 2025 and is iterating fast. TSLint is dead, and any tool in long-term maintenance mode is a risk for a monorepo expected to live five years.

These criteria reflect what a TypeScript monorepo maintainer actually weighs when picking a linter. Speed and type-aware rule coverage are the two largest factors and they trade off against each other. Plugin ecosystem depth is the constraint that keeps many teams on ESLint regardless of speed. Formatter integration and workspace-level rules round out the decision because a monorepo wants the smallest set of tools that still cover the whole quality surface.

Where AI looks

No sources surfaced yet.

Source citations will populate once the tracked prompts have run. Based on the broader research landscape, expect Perplexity and ChatGPT to lean on PkgPulse, Better Stack, LogRocket, the oxc.rs benchmarks page, the Biome and ESLint documentation sites, and a long tail of comparison posts on Dev.to and Medium. We will surface the actual cited domains in the next refresh.

FAQ

What is the best linter for a TypeScript monorepo in 2026?
There is no single answer. Biome is the strongest all-in-one choice for new monorepos because it ships linting and formatting in one Rust binary, runs 10 to 20 times faster than ESLint, and v2 added type-aware rules that cover most of what typescript-eslint provides. ESLint with typescript-eslint stays the answer when the monorepo depends on framework plugins for React, Next.js, Vue, or testing libraries. Oxlint is the fastest pure linter and works best as a CI accelerator alongside ESLint rather than a full replacement.
ESLint vs Biome for a TypeScript monorepo, which one should I pick?
For a fresh monorepo, Biome wins on speed, on developer experience (one tool for lint and format), and on simpler config. For an established monorepo with heavy plugin usage, ESLint is still the lower-risk choice because every plugin you depend on already exists. Biome v2 closed most of the type-aware rule gap, so the case for migration in 2026 is stronger than it was a year ago.
Is Oxlint a drop-in replacement for ESLint?
Not yet. Oxlint covers around 300 rules versus ESLint with typescript-eslint at 700 plus, has no plugin system, and lacks full type-aware lint rules. The recommended pattern in 2026 is to run Oxlint first in CI for the fast majority of checks and let ESLint handle the rules Oxlint does not yet implement. That dual setup gives most of the speed-up without losing rule coverage.
How fast is Biome compared to ESLint on a real monorepo?
Reported benchmarks put Biome at 10 to 20 times faster than ESLint, and Oxlint at 50 to 100 times faster. A repo that takes ESLint 30 to 45 seconds typically finishes in under a second with Biome and under half a second with Oxlint. The exact ratio depends on rule selection and whether type-aware rules are enabled, since type-aware checking makes any linter slower.
Does Biome work with Turborepo and Nx?
Yes. Biome runs as a normal CLI command, so any Turborepo or Nx pipeline that runs eslint can run biome check in the same slot, with the same caching behaviour. Biome supports nested config files, which maps cleanly to a Turborepo workspace where each package can override the root config. The same applies to Oxlint.
Do I still need Prettier if I use Biome?
No. Biome includes a formatter that aims for Prettier-compatible output and handles JS, TS, JSX, JSON, and CSS in one tool. Most teams that move to Biome remove Prettier entirely. If you stay on ESLint or Oxlint, Prettier or dprint remains the formatting answer.
What about workspace-level issues like duplicate dependencies?
Code linters do not check workspace hygiene. Sherif is the dedicated tool for that, with rules for duplicate dependencies, missing peer dependencies, and version drift across packages. Most TypeScript monorepos in 2026 run a code linter (Biome, ESLint, or Oxlint) alongside Sherif and Knip, which catches unused files, exports, and dependencies.
How was this list built?
We compiled the shortlist from the linters that recur across PkgPulse, Better Stack, LogRocket, oxc.rs benchmarks, and independent comparison reviews aimed at TypeScript monorepo maintainers in 2026. Tracked prompts have been queued and will run weekly against the Pro-default AI models, so future refreshes will rank the tools by how often each AI model recommends them. See the methodology page for the full process.

Read the methodology.

Methodology: how we source and measure.