5 ms·

You could have the linter only run on changed files in a precommit hook, instead of on all files.

by jabo 5y ago

foreigner 5y ago
That would work at file level granularity, but I'd like it to work at line level.
- masklinn 5y ago
  You can usually take the output of the lint tool and filter it by the lines modified by the patch (which you get from the diff). Few tools do it out of the box (in the python world flake8 supports diff filtering out of the box, and there's diff-cover which can filter analysis beyond just test coverage) but it's easy enough to do with a wrapper, especially if the linter has a configurable or even parseable (e.g. json) output option.
- jabo 5y ago
  Found an ESLint plugin that will only run on staged changes: https://www.npmjs.com/package/eslint-plugin-diff https://www.npmjs.com/package/eslint-plugin-diff
surfmike 5y ago
This still leads to frustrating behavior, where changing one line of a file might end up reformatting all of it (and this often obscures the actual change itself).
- klodolph 5y ago
  Tools like git-clang-format only reformat the code you’ve changed, not the entire file. A lot of formatting tools work this way (certainly not all).
- jabo 5y ago
  There’s an eslint plugin to run only on staged changes: https://news.ycombinator.com/item?id=27643526 https://news.ycombinator.com/item?id=27643526
  - foreigner 5y ago
    That looks perfect.
    - onion2k 5y ago
      There's also the 'lint-staged' NPM package if you want to do pretty much anything only on staged files.
      - morelisp 5y ago
        I can't remember if this package specifically was one of the ones we tried (it was 3-4 different packages in the JS ecosystem), but anything that pretends files and not changes are the units of staging will cause problems for advanced git workflows.
- cratermoon 5y ago
  At one job I pushed back against a drive to introduce a pre-commit "format to standard" hook. Aside from the fact that nobody was really advocating for it other than one programmer who had, shall we say, a certain outlook, I have never wanted to see a commit that had both the relevant change and formatting fixes. While the "reformat lines that have changed" kind of works, you can end up with code that is half one style and half another, which is worse for comprehension than having it all one style, even if that style is a bad one. This wasn't Python, so at least we didn't have to worry that an automatic reformat could literally change the behavior of an entire block. There are still edge cases in most languages, around control structures, i.e. the infamous braceless "if". I think the implementers of the Go language got it right: there's one style, for everyone. Like it or hate it, there's no Holy War over it.

You could have the linter only run on changed files in a precommit hook, instead of on all files.

by jabo 5y ago

You could have the linter only run on changed files in a precommit hook, instead of on all files.

foreigner 5y ago

That would work at file level granularity, but I'd like it to work at line level.

masklinn 5y ago
You can usually take the output of the lint tool and filter it by the lines modified by the patch (which you get from the diff). Few tools do it out of the box (in the python world flake8 supports diff filtering out of the box, and there's diff-cover which can filter analysis beyond just test coverage) but it's easy enough to do with a wrapper, especially if the linter has a configurable or even parseable (e.g. json) output option.
jabo 5y ago
Found an ESLint plugin that will only run on staged changes: https://www.npmjs.com/package/eslint-plugin-diff https://www.npmjs.com/package/eslint-plugin-diff

surfmike 5y ago

This still leads to frustrating behavior, where changing one line of a file might end up reformatting all of it (and this often obscures the actual change itself).

klodolph 5y ago
Tools like git-clang-format only reformat the code you’ve changed, not the entire file. A lot of formatting tools work this way (certainly not all).
jabo 5y ago
There’s an eslint plugin to run only on staged changes: https://news.ycombinator.com/item?id=27643526 https://news.ycombinator.com/item?id=27643526
- foreigner 5y ago
  That looks perfect.
  - onion2k 5y ago
    There's also the 'lint-staged' NPM package if you want to do pretty much anything only on staged files.
    - morelisp 5y ago
      I can't remember if this package specifically was one of the ones we tried (it was 3-4 different packages in the JS ecosystem), but anything that pretends files and not changes are the units of staging will cause problems for advanced git workflows.
cratermoon 5y ago
At one job I pushed back against a drive to introduce a pre-commit "format to standard" hook. Aside from the fact that nobody was really advocating for it other than one programmer who had, shall we say, a certain outlook, I have never wanted to see a commit that had both the relevant change and formatting fixes. While the "reformat lines that have changed" kind of works, you can end up with code that is half one style and half another, which is worse for comprehension than having it all one style, even if that style is a bad one. This wasn't Python, so at least we didn't have to worry that an automatic reformat could literally change the behavior of an entire block. There are still edge cases in most languages, around control structures, i.e. the infamous braceless "if". I think the implementers of the Go language got it right: there's one style, for everyone. Like it or hate it, there's no Holy War over it.