ESLint vs. Deno Lint

[pubmikeb]

Nowadays, ESLint is the de facto gold standard for linting JS code, while typescript-eslint recommended for TS. With the release of version 9.0, ESLint is moving towards being «a more general-purpose linter that is capable of linting any language», currently supporting JSON, Markdown, CSS, and more to come.

Given all of the above, including the vast set of existing rules, phenomenal flexibility, and active development status of ESLint, what's the point of investing resources on reinventing the wheel with Deno Lint? What's unique about Deno Lint, other than the increased speed of linting a limited, comparing to ESLint, set of rules thanks to its Rust-implementation?

[marvinhagemeister]

Advantages of deno lint:

• Is already included in Deno, no need to install additional packages.
• Running Rust lint rules is 20-50x faster typically. Might not matter for small projects, but for big projects the difference is very noticeable.
• Deno's Linter has a couple of rules that can verify the module graph
• We recently launched an ESLint compatible plugin system for deno lint so that ESLint rules can run directly in deno lint. So far the eslint plugin structure is supported, with config support on the horizon. The main motivation behind this was exactly what you're asking for: To not have to do duplicate work and not re-invent the wheel. In a way we're already going in the direction you're asking about.

You might think that performance doesn't matter as much, but I've worked on projects where ESLint took 1:15 hours (!) to do a full linting pass and a Rust-based linter could do the same thing in 2.5s . That's a significant difference. On most projects deno lint completes in a blink of an eye. Having immediate feedback on your code is quite nice instead of having to wait for it. If you don't work on bigger projects then this aspect might not be as critical to you as it is to others.

But then again we're already taking steps in the direction to support running existing ESLint rules, so that the wheel isn't reinvented.

[pubmikeb]

@marvinhagemeister, thanks for the quick response!

To not have to do duplicate work and not re-invent the wheel.

This is great news! ESLint has a ton of useful rules that greatly improve the quality of a codebase, and it would be great to be able to run all of them 20-50x faster!

[marvinhagemeister]

Are there specific rules in particular that you're missing in Deno? Note that the difference in performance mostly comes from rewriting the rules in Rust. The performance of the JavaScript plugin system will be likely around the same as ESLint (maybe a little faster, but not much).

[pubmikeb]

I'm just exploring the Deno environment, therefore I can't name the specific rules, which I miss in Deno, but actively using in ESLint, especially bearing in mind the amount of existing ESLint rules.