3 ms·
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
by foreigner 5y ago
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.
- jabo 5y agoYou could have the linter only run on changed files in a precommit hook, instead of on all files.
- foreigner 5y agoThat would work at file level granularity, but I'd like it to work at line level.
- masklinn 5y agoYou 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 agoFound 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 agoThis 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 agoTools 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 agoThere’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 agoThat looks perfect.
- onion2k 5y agoThere's also the 'lint-staged' NPM package if you want to do pretty much anything only on staged files.
- morelisp 5y agoI 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 agoAt 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.
- foreigner 5y agoI 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.
- FalconSensei 5y agoOn 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
- scns 5y agoThank you
- IshKebab 5y agoPhabricator's Arcanist tool works like that, but I wouldn't recommend it. That's how you end up with completely inconsistently formatted files.