Hacker News Reader

Comment by jabo | Hacker News Reader

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

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).

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).

There’s an eslint plugin to run only on staged changes: https://news.ycombinator.com/item?id=27643526

That looks perfect.

There's also the 'lint-staged' NPM package if you want to do pretty much anything only on staged files.

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.

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.

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

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.

Found an ESLint plugin that will only run on staged changes: https://www.npmjs.com/package/eslint-plugin-diff

Reply on news.ycombinator.com