3 ms·

> it serves as an enhancement when ESLint's slowness becomes a bottleneck in your workflow Well, when I need to batch fix errors in files, yes it can take a wh

by d3w4s9 3y ago

> it serves as an enhancement when ESLint's slowness becomes a bottleneck in your workflow Well, when I need to batch fix errors in files, yes it can take a while to run eslint. But that almost never happens. I have the plugin and fix errors as I go (which I believe is what most people do), and I never feel performance is an issue in this workflow. I really doubt how (actually) useful this is.

jcelerier 3y ago
It's still using more battery
- d3w4s9 3y ago
  True, but eslint energy use would be one of the last things I worry about if I am looking for a longer battery life. Chances are that TypeScript service used for Intellisense costs more electricity.
sapiogram 3y ago
Their main motivation seems to be CI, where people often lint the entire repo on every PR.
- msoad 3y ago
  which is a really weird problem to have. Only lint files that have changed? How hard that is? our monorepo is 3m lines of code and running lint is not a bottleneck by any means... And once in a while that we have to run lint for entire repo (ESLint upgrade for example) we can afford to wait 1 hour ONCE
  - Aeolos 3y ago
    50-100x faster would turn that 1 hour into 1 minute. It's not that you can't wait 1 hour, it's that you don't have to wait. Think of all the wasted cycles that could be put to better use...
  - ForkMeOnTinder 3y ago
    > Only lint files that have changed? How hard that is? Quite hard, especially since type-aware rules from e.g. https://typescript-eslint.io/ https://typescript-eslint.io/ mean that changing the type of a variable in file A can break your code in file B, even if file B hasn't changed.
    - msoad 3y ago
      Well, this solution won't help with those rules since your bottleneck is now tsc.
  - mrkeen 3y ago
    > we can afford to wait 1 hour ONCE If you lint the entire repo, fix every issue in one try on the first go, and then lint the entire repo to double-check, that's two hours. But my workflow is usually: lint the repo -> fix one thing -> repeat
deleted 3y ago
[deleted]
zanellato19 3y ago
Are you kidding? Having someone run faster on the editor is a huge gain. I can't believe people are saying this isn't useful.
- d3w4s9 3y ago
  Faster by how much in absolute time? Currently I'm not feeling ANY delay in the IDE, so I assume for a regular size file linting takes less than 50ms -- likely much shorter than that. Let's say it reduces 50ms to 2ms. Guess what? It still has absolutely no effect on my everyday work.

by d3w4s9 3y ago

jcelerier 3y ago

It's still using more battery

d3w4s9 3y ago
True, but eslint energy use would be one of the last things I worry about if I am looking for a longer battery life. Chances are that TypeScript service used for Intellisense costs more electricity.

sapiogram 3y ago

Their main motivation seems to be CI, where people often lint the entire repo on every PR.

msoad 3y ago
which is a really weird problem to have. Only lint files that have changed? How hard that is? our monorepo is 3m lines of code and running lint is not a bottleneck by any means... And once in a while that we have to run lint for entire repo (ESLint upgrade for example) we can afford to wait 1 hour ONCE
- Aeolos 3y ago
  50-100x faster would turn that 1 hour into 1 minute. It's not that you can't wait 1 hour, it's that you don't have to wait. Think of all the wasted cycles that could be put to better use...
- ForkMeOnTinder 3y ago
  > Only lint files that have changed? How hard that is? Quite hard, especially since type-aware rules from e.g. https://typescript-eslint.io/ https://typescript-eslint.io/ mean that changing the type of a variable in file A can break your code in file B, even if file B hasn't changed.
  - msoad 3y ago
    Well, this solution won't help with those rules since your bottleneck is now tsc.
- mrkeen 3y ago
  > we can afford to wait 1 hour ONCE If you lint the entire repo, fix every issue in one try on the first go, and then lint the entire repo to double-check, that's two hours. But my workflow is usually: lint the repo -> fix one thing -> repeat

deleted 3y ago

[deleted]

zanellato19 3y ago

Are you kidding? Having someone run faster on the editor is a huge gain. I can't believe people are saying this isn't useful.

d3w4s9 3y ago
Faster by how much in absolute time? Currently I'm not feeling ANY delay in the IDE, so I assume for a regular size file linting takes less than 50ms -- likely much shorter than that. Let's say it reduces 50ms to 2ms. Guess what? It still has absolutely no effect on my everyday work.