Hacker News Reader

Comment by foreigner | Hacker News Reader

On this topic, is there a JavaScript lint tool that integrates with Git to enable you to gradually apply style changes to code as it evolves? E.g. if the change is tabs-to-spaces the lint tool would require spaces in new or changed lines of code, but not complain about tabs in unchanged lines of existing code.

View on HN

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

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

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.

On IntelliJ, if you use the Save Actions plugin, you can set it to only reformat lines that were changed. Although I'm not sure if would work for using Prettier

Thank you

I guess one way this might work is the lint tool could run against the whole file but then cross-check the line numbers of any errors found with the git diff. If the diff shows the line is unchanged then ignore the error. That doesn't sound too hard.

Phabricator's Arcanist tool works like that, but I wouldn't recommend it. That's how you end up with completely inconsistently formatted files.

Reply on news.ycombinator.com