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.<p><a href="https://eslint.org/docs/latest/use/getting-started" rel="nofollow">https://eslint.org/docs/latest/use/getting-started</a><p>> 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.<p>Which means that simple stuff like just adding the airbnb or eslint recommended settings can now only be done locally.<p>More discussion here: <a href="https://github.com/eslint/eslint/issues/11914">https://github.com/eslint/eslint/issues/11914</a><p>And here: <a href="https://github.com/jsx-eslint/eslint-plugin-react/issues/2339">https://github.com/jsx-eslint/eslint-plugin-react/issues/233...</a><p>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 <i>everything.</i><p>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.<p>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.<p>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.<p>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.<p>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.<p>But "use what you know" I suppose.<p>Finally, I am really glad this post did not mention the initialisms "LLM" or "AI".<p>[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<p>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.