3 ms·

Do you have some source files that are somehow exempt from bugs and would be a waste of the linter's time? Probably not, but it's a trick question: if you try

Do you have some source files that are somehow exempt from bugs and would be a waste of the linter's time? Probably not, but it's a trick question: if you try to look for exceptions to the rule, you have already wasted so much time that running a linter on all files would be faster.

thfuran 3y ago
>Do you have some source files that are somehow exempt from bugs and would be a waste of the linter's time? Every file not touched in any given diff
- Shish2k 3y ago
  If I change a function signature, then my code is fine - but all the other files which import and use my function will break
  - zdragnar 3y ago
    That's a job for TypeScript, not eslint.
    - kristiandupont 3y ago
      Linter rules can rely on the type system
      - zdragnar 3y ago
        What eslint rule would apply to the caller of a function after that function's signature changes that wouldn't also be picked up by TypeScript? In particular, the call site itself hasn't changed, as this thread assumes the linter is only run on changed files
        kristiandupont 3y ago
        Anamexis has a couple of examples in this response: https://news.ycombinator.com/item?id=38655101 https://news.ycombinator.com/item?id=38655101
- OJFord 3y ago
  What if the diff adds a new linter rule, should we only run it on the linter config file? What if the linter uses more context than a single file, a type-checker for example or even just checking the correct number of arguments (regardless of type) are passed to an imported function - or that that symbol is indeed even callable? Should we only run the linter on the caller's file, or the callee's, when they haven't both changed?
  - ehutch79 3y ago
    Run the linter on the code base then, when you make the change? Not every check-in on the off chance a rule changed. Or, add some logic that the CI runs it against the whole code base only when the rules changed, otherwise just the relevant files to the commit/pr Also, ESLint doesn't do type checking. That's typescripts job, and apparently typescripts runtime isn't an issue.
- spenczar5 3y ago
  If a different (unchanged) file depends on the one you changed, you could have changed the API in a way that makes the unchanged file unacceptable to your linter.

thfuran 3y ago

>Do you have some source files that are somehow exempt from bugs and would be a waste of the linter's time? Every file not touched in any given diff

Shish2k 3y ago
If I change a function signature, then my code is fine - but all the other files which import and use my function will break
- zdragnar 3y ago
  That's a job for TypeScript, not eslint.
  - kristiandupont 3y ago
    Linter rules can rely on the type system
    - zdragnar 3y ago
      What eslint rule would apply to the caller of a function after that function's signature changes that wouldn't also be picked up by TypeScript? In particular, the call site itself hasn't changed, as this thread assumes the linter is only run on changed files
      - kristiandupont 3y ago
        Anamexis has a couple of examples in this response: https://news.ycombinator.com/item?id=38655101 https://news.ycombinator.com/item?id=38655101
OJFord 3y ago
What if the diff adds a new linter rule, should we only run it on the linter config file? What if the linter uses more context than a single file, a type-checker for example or even just checking the correct number of arguments (regardless of type) are passed to an imported function - or that that symbol is indeed even callable? Should we only run the linter on the caller's file, or the callee's, when they haven't both changed?
- ehutch79 3y ago
  Run the linter on the code base then, when you make the change? Not every check-in on the off chance a rule changed. Or, add some logic that the CI runs it against the whole code base only when the rules changed, otherwise just the relevant files to the commit/pr Also, ESLint doesn't do type checking. That's typescripts job, and apparently typescripts runtime isn't an issue.
spenczar5 3y ago
If a different (unchanged) file depends on the one you changed, you could have changed the API in a way that makes the unchanged file unacceptable to your linter.