6 ms·

What's Coming Next for ESLint

32 points by soheilpro 2y ago

mediumsmart 2y ago
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.
spoiler 2y ago
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!
- jerrygoyal 2y ago
  wish if it could support eslint plugins
  - hoffs 2y ago
    Ironic
    - morbicer 2y ago
      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.
  - spoiler 2y ago
    Which lints are you missing?
- floydnoel 2y ago
  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!
moogly 2y ago
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.
- andenacitelli 2y ago
  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.
suzzer99 2y ago
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 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 https://github.com/eslint/eslint/issues/11914 And here: https://github.com/jsx-eslint/eslint-plugin-react/issues/2339 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.
- elondaits 2y ago
  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.
  - suzzer99 2y ago
    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.
- thiht 2y ago
  > 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"?
move-on-by 2y ago
> 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?
- thiht 2y ago
  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.
egorfine 2y ago
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.

32 points by soheilpro 2y ago

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.

spoiler 2y ago

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!

jerrygoyal 2y ago
wish if it could support eslint plugins
- hoffs 2y ago
  Ironic
  - morbicer 2y ago
    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.
- spoiler 2y ago
  Which lints are you missing?
floydnoel 2y ago
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!

moogly 2y ago

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.

andenacitelli 2y ago
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.

suzzer99 2y ago

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 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 https://github.com/eslint/eslint/issues/11914 And here: https://github.com/jsx-eslint/eslint-plugin-react/issues/2339 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.

elondaits 2y ago
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.
- suzzer99 2y ago
  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.
thiht 2y ago
> 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"?

move-on-by 2y ago

> 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?

thiht 2y ago
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.

egorfine 2y ago

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.