3 ms·

75 minutes to generate a bunch of mostly irrelevant nitpicks. What a colossal waste of compute resources. (1) IME if you’re using TypeScript then ESlint’s rea

by davedx 3y ago

75 minutes to generate a bunch of mostly irrelevant nitpicks. What a colossal waste of compute resources. (1) IME if you’re using TypeScript then ESlint’s real value mostly approaches zero. For pure JS projects it’s useful for finding nullref type bugs. (1) > Our previous linting setup took 75 minutes to run, so we were fanning it out across 40+ workers in CI This. Is. Insane.

ehutch79 3y ago
Disagree on ESLint vs Typescript. ESLint and TyepScripts jobs should have minimal overlap. ESLint primary job is linting. It should be finding 'foot guns' and code style issues. Things that are absolutely valid in the language, but could lead to potential issues. Because of that, it's totally valid that you're not finding as much value in it. It depends on the rules you enable in it, etc. And yeah, it can feel super nitpicky when it's yelling at you for not having a radix in parseInt(). Typescript's 'compile' step or whatever, it doing type checking and making sure your code is valid. If you're using bare JS, your IDE should be doing this job, not eslint. (but yes, anything more than a few minutes to lint even a large code base is insane.)
padjo 3y ago
“rules of hooks” linting alone prevents a ton of bugs in your average React codebase and TS will provide no help there
- davedx 3y ago
  Ah yes the “exhaustive dependencies” rule that can trigger huge unnecessary refactors for absolutely zero value. Linting has some value, it’s just that in my professional experience its costs outweigh its benefits
  - padjo 3y ago
    If you leave dependencies off a hook by mistake you’re creating bugs, unintended behaviour and making your code a nightmare to modify. That’s always going to be worth linting for. Can you over lint a codebase, sure I guess so, if your lint stage is taking hours it probably needs optimization, but your assertion that type checking is enough is incorrect.
    - davedx 3y ago
      Having to specify every single closure in dependencies does nothing. Not every dependency has to be specified. Not specifying a dependency is not always a bug. Honestly if not exhaustively putting some closures in your useEffect deps list is your idea of a “maintenance nightmare” then maybe you should stay away from real production code bases? There are plenty of hairier mistakes and patterns out there than that.
clarkdave 3y ago
I think the typescript-eslint plugin in particular has some high value eslint rules that complement TypeScript. For example, the no-floating-promise[0] rule catches some easily-made mistakes involving promises in a way that TypeScript doesn't on its own. Other rules can be used to increase type safety further. There are various rules relating to `any`, like no-unsafe-argument[1], which can be helpful to prevent such types sneaking into your code without realising it; TS has `noImplicitAny`, but it'll still let you run something like `JSON.parse()` and pass the resulting any-typed value around without checking it. [0] https://typescript-eslint.io/rules/no-floating-promises https://typescript-eslint.io/rules/no-floating-promises [1] https://typescript-eslint.io/rules/no-unsafe-argument https://typescript-eslint.io/rules/no-unsafe-argument
- seanwilson 3y ago
  > For example, the no-floating-promise[0] rule catches some easily-made mistakes involving promises in a way that TypeScript doesn't on its own. Is there a fast linter that checks for this? I find this error easy to make as well, and it usually causes weird runtime behaviour that's hard to track down.
smt88 3y ago
TypeScript is still permissive because it has to maintain compatibility with JS. We use eslint for formatting and other legal-but-likely-a-mistake behavior and it does catch bugs.
eyelidlessness 3y ago
I get a ton of value from ESLint with TypeScript, and in particular from @typescript-eslint. And yes, 75 minutes is absolutely bonkers. It would have me rethinking a lot of things well short of that time. But automated quality checks wouldn’t be anywhere near the top of that rethinking list. And partly, but not only, because of irrelevant nitpicks. Having humans do those nitpicks is vastly worse in time elapsed, and likely in compute time in many scenarios as well. The more human time is spent on the things linters help with, the more that time is not spent on reviewing and ensuring correctness, performance, design, maintainability, user- and business-implications, etc.

by davedx 3y ago

ehutch79 3y ago

Disagree on ESLint vs Typescript. ESLint and TyepScripts jobs should have minimal overlap. ESLint primary job is linting. It should be finding 'foot guns' and code style issues. Things that are absolutely valid in the language, but could lead to potential issues. Because of that, it's totally valid that you're not finding as much value in it. It depends on the rules you enable in it, etc. And yeah, it can feel super nitpicky when it's yelling at you for not having a radix in parseInt(). Typescript's 'compile' step or whatever, it doing type checking and making sure your code is valid. If you're using bare JS, your IDE should be doing this job, not eslint. (but yes, anything more than a few minutes to lint even a large code base is insane.)

padjo 3y ago

“rules of hooks” linting alone prevents a ton of bugs in your average React codebase and TS will provide no help there

davedx 3y ago
Ah yes the “exhaustive dependencies” rule that can trigger huge unnecessary refactors for absolutely zero value. Linting has some value, it’s just that in my professional experience its costs outweigh its benefits
- padjo 3y ago
  If you leave dependencies off a hook by mistake you’re creating bugs, unintended behaviour and making your code a nightmare to modify. That’s always going to be worth linting for. Can you over lint a codebase, sure I guess so, if your lint stage is taking hours it probably needs optimization, but your assertion that type checking is enough is incorrect.
  - davedx 3y ago
    Having to specify every single closure in dependencies does nothing. Not every dependency has to be specified. Not specifying a dependency is not always a bug. Honestly if not exhaustively putting some closures in your useEffect deps list is your idea of a “maintenance nightmare” then maybe you should stay away from real production code bases? There are plenty of hairier mistakes and patterns out there than that.

clarkdave 3y ago

I think the typescript-eslint plugin in particular has some high value eslint rules that complement TypeScript. For example, the no-floating-promise[0] rule catches some easily-made mistakes involving promises in a way that TypeScript doesn't on its own. Other rules can be used to increase type safety further. There are various rules relating to `any`, like no-unsafe-argument[1], which can be helpful to prevent such types sneaking into your code without realising it; TS has `noImplicitAny`, but it'll still let you run something like `JSON.parse()` and pass the resulting any-typed value around without checking it. [0] https://typescript-eslint.io/rules/no-floating-promises https://typescript-eslint.io/rules/no-floating-promises [1] https://typescript-eslint.io/rules/no-unsafe-argument https://typescript-eslint.io/rules/no-unsafe-argument

seanwilson 3y ago
> For example, the no-floating-promise[0] rule catches some easily-made mistakes involving promises in a way that TypeScript doesn't on its own. Is there a fast linter that checks for this? I find this error easy to make as well, and it usually causes weird runtime behaviour that's hard to track down.

smt88 3y ago

TypeScript is still permissive because it has to maintain compatibility with JS. We use eslint for formatting and other legal-but-likely-a-mistake behavior and it does catch bugs.

eyelidlessness 3y ago

I get a ton of value from ESLint with TypeScript, and in particular from @typescript-eslint. And yes, 75 minutes is absolutely bonkers. It would have me rethinking a lot of things well short of that time. But automated quality checks wouldn’t be anywhere near the top of that rethinking list. And partly, but not only, because of irrelevant nitpicks. Having humans do those nitpicks is vastly worse in time elapsed, and likely in compute time in many scenarios as well. The more human time is spent on the things linters help with, the more that time is not spent on reviewing and ensuring correctness, performance, design, maintainability, user- and business-implications, etc.