What's Coming Next for ESLint

The weird hostile attitude ESLint has about using global config really bums me out. Not everyone wants to install ESLint in every package.json. I work in more than 30 active repos. I want global eslint to just work for most of them, and specific ESLint to work for a few. This used to work fine, now it doesn't.

https://eslint.org/docs/latest/use/getting-started

> It is also possible to install ESLint globally, rather than locally, using npm install eslint --global. However, this is not recommended, and any plugins or shareable configs that you use must still be installed locally if you install ESLint globally.

Which means that simple stuff like just adding the airbnb or eslint recommended settings can now only be done locally.

More discussion here: https://github.com/eslint/eslint/issues/11914

And here: https://github.com/jsx-eslint/eslint-plugin-react/issues/233...

Not everyone works on giant teams where global settings that aren't part of the project become a nightmare for compatibility. We have a very small team with often just one developer doing most of the work on a project.

They have released version 9.0 which broke everything.

A web tutorial you have read for a quickstart? Obsolete and not working. Any solution on stackoverflow? Nope, not applicable anymore. A lint rules package that was used by thousands upon thousands of projects world-wide (like Airbnb's one)? Not compatible. Your project's linter rules carefully tuned for years? Broken.

So we're staying on 8.x until at least Airbnb updates their package and they don't rush. Meaning that practically eslint has been now split into two worlds: working 8.x and a "future" 9.x. Not sure how much time it will take for the industry to catch up.

I can't help but wonder whether the new config system was worth such drastic changes and pain.

I know I'm being a bit negative with regards to ESLint, but I'd just go with BiomeJS these days. It's faster and more sensible with its default lints.

And to boot it comes with a very sensible (and Prettier compatible) formatter!

Since they are going to split it into parts and rewrite some of them, I see an opportunity to rewrite those parts in Rust or Go a la swc or esbuild. Whilst I'm sure a rewrite in JS or TS could improve performance too, the fact remains that ESLint is a massive part of build times across the ecosystem. I don't even want to think about how many monthly hours computers spend in ESLint, especially translated to MWh.

Since it seems they want to have it runnable in the browser (not exactly sure why[1]), I guess Rust would be more amenable to that with its WASM targets.

But "use what you know" I suppose.

Finally, I am really glad this post did not mention the initialisms "LLM" or "AI".

[1]: Being able to easily make a site where you paste code in a textarea and get it linted is my best guess, but that seems like it should not be a core feature, since it is not its primary use case, and can instead be done via a WASM bridge or something.

> Two years ago, the TSC decided that it was time to open up ESLint to make it possible to lint languages other than JavaScript

Are people really asking for this? It seems to me what people want is speed- which is where all these new tools are popping up with Rust. Who is asking for ESLint for other languages?

I am happy with a subset of JavaScript that passes jslint.com but I can understand the fatal attraction of a linter cloud of plugins that can lint all the languages.