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.
> 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.
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.
With JetBrains IDEs (e.g. Webstorm) it’s posible to point the IDE to a central installation of ESlint (independent from the project you’re working on). I use that for smaller projects where I don’t want to include a full installation of ESLint within the list of dependencies.
Yeah I'm an old dinosaur still on SublimeText. For me, quickly searching across all my repos is the most important feature, and I like Sublime's search the best.
Also I have so many keyboard shortcuts memorized to where I couldn't even tell the shortcut, my hands just do it on command.
1. It slows down CICD install times for every repo.
2. I'd rather not have to make the same ESLint config change to 30+ repos.
3. I'd rather not have to update ESLint plus plugins in 30+ package.json files.'
We don't use ESLint as any kind of CICD gateway and we don't enforce what IDE/linter people use. It's not important to us to have perfect uniformity across every developer's machine.
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've been looking into Biome as ESLint can't parse the 'with' keyword from TC39 (import attributes) which is supported in Node for a while now. No combination of plugins, ignores, or configurations can help because ESLint can't parse the file at all. Best I could do was disable ESLint for those files.
I found Biome when looking at solutions, but i hadn't heard of anyone using or recommending it. I'll take a look and see if we can replace ESLint to handle that issue. Thanks!
Why? Rspack supports webpack plugins even tho it's written in Rust. That's how you win at adoption.
If Biome would support plugins the answer to post title "What's coming next for ESLint" will be "slide to obsolescence".
Without it ESLint is going to cling on legacy codebases for a bit longer.
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.
A full rewrite instead of finding a way to gradually increment already feels like a lot of risk. Asking your core dev team to potentially pick up an entirely new skillset in Rust would introduce too much on top and probably cause people to flake from the project.
Totally agree something like Rust would be good in a vacuum, but existing contributors and ecosystem would present problems. Having tooling built in the same ecosystem as the end product makes it way easier to contribute.
> 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.
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.
With JetBrains IDEs (e.g. Webstorm) it’s posible to point the IDE to a central installation of ESlint (independent from the project you’re working on). I use that for smaller projects where I don’t want to include a full installation of ESLint within the list of dependencies.
Yeah I'm an old dinosaur still on SublimeText. For me, quickly searching across all my repos is the most important feature, and I like Sublime's search the best.
Also I have so many keyboard shortcuts memorized to where I couldn't even tell the shortcut, my hands just do it on command.
> Not everyone wants to install ESLint in every package.json
I don’t understand why? Adding the config to the repo takes minutes, and then you’re good: it’s shared with all the contributors and can work in CI.
Not sure why you would want to settle for "works on my machine"?
1. It slows down CICD install times for every repo.
2. I'd rather not have to make the same ESLint config change to 30+ repos.
3. I'd rather not have to update ESLint plus plugins in 30+ package.json files.'
We don't use ESLint as any kind of CICD gateway and we don't enforce what IDE/linter people use. It's not important to us to have perfect uniformity across every developer's machine.
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!
I've been looking into Biome as ESLint can't parse the 'with' keyword from TC39 (import attributes) which is supported in Node for a while now. No combination of plugins, ignores, or configurations can help because ESLint can't parse the file at all. Best I could do was disable ESLint for those files.
I found Biome when looking at solutions, but i hadn't heard of anyone using or recommending it. I'll take a look and see if we can replace ESLint to handle that issue. Thanks!
wish if it could support eslint plugins
Which lints are you missing?
Ironic
Why? Rspack supports webpack plugins even tho it's written in Rust. That's how you win at adoption.
If Biome would support plugins the answer to post title "What's coming next for ESLint" will be "slide to obsolescence". Without it ESLint is going to cling on legacy codebases for a bit longer.
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.
A full rewrite instead of finding a way to gradually increment already feels like a lot of risk. Asking your core dev team to potentially pick up an entirely new skillset in Rust would introduce too much on top and probably cause people to flake from the project.
Totally agree something like Rust would be good in a vacuum, but existing contributors and ecosystem would present problems. Having tooling built in the same ecosystem as the end product makes it way easier to contribute.
> 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?
2 sentences later :
> we kept finding plugins that were linting other languages (like GraphQL and HTML) from within ESLint
Every JS/TS codebase also contains Markdown, JSON, HTML, CSS files, and more. So it makes sense to support these as well, I guess.
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.