ESLint Adds Support for Parallel Linting, Closing 10-Year-Old Feature Request

Amid a wave of new JavaScript linters built for speed and type-awareness, ESLint, the incumbent linter, is rolling out a major performance upgrade of its own. Parallel linting, first requested more than 10 years ago, is set to land in core after the merging a PR that implemented the design from an RFC.

The new feature introduces a --concurrency flag that spreads linting work across multiple CPU cores. Setting --concurrency=auto picks an optimal number of threads automatically, while developers can also fine-tune the number of workers. On larger projects, community benchmarks show dramatic improvements, with lint times cut by 30–60% and in some cases more than 3x faster.

Resolving ESLint’s Oldest Performance Complaint#

The effort traces back to issue #3565, opened in 2015, which became one of the most upvoted requests in ESLint’s history. For years, developers asked when ESLint would be able to lint files in parallel, often pointing to the growing pain of large TypeScript and monorepo setups.

After nearly a decade of discussion, the approach was formalized in RFC 129, which described the feature as multithread linting. Contributor Francesco Trotta (@fasttime) then implemented the design in a sweeping pull request, adding:

• Worker thread orchestration for file-level linting.
• A concurrency flag for both CLI and Node.js API users.
• Safeguards to avoid wasted threads on small projects, including warnings when too many workers slow things down.

Benchmarks posted during review helped prove the approach. Results included ESLint’s own repo (~1k files) running 30% faster, large monorepos like OpenUI5 (~12k files) running up to 60% faster, and the Node.js project seeing nearly 4x improvements on Apple silicon.

Sentry engineer Dominik Dorfmeister reported trying the feature on the Sentry codebase and saw an instant 35% reduction in CI linting time with --concurrency=2.

The New Era of Stack-Aligned Linters#

This update is expected to roll out this week in the next release, landing alongside Oxlint's previewed type-aware linting and Rspack's introduction of Rslint, a TypeScript-first linter written in Go. Both projects are betting on typescript-go to make typed linting fast enough for everyday use.

While the new challengers focus on typed rules and compiler-level integration, ESLint’s latest update shows the incumbent linter is still evolving, closing a 10-year-old feature request and scaling better for the largest codebases in the ecosystem.

The broader trend is toward purpose-built linters: Oxlint, Rslint, Biome, and others are each tuned to different priorities like speed, typed analysis, or ecosystem consistency. Instead of one default choice, developers now face a growing menu of specialized tools, with the option to select the linter that best fits their stack and workflow.