Please add "--diff" command line flag that just runs eslint on the diff

The problem you want to solve. There is currently no way to run eslint on a diff. So there is no reliable way to use it as pre-commit hook. Eslint even points people to this gist claiming it “only lints staged changes”. That is a dang lie! It only lints staged files. And it lints them as they are on disk, not in git, so the suggested pre-commit hook can fail for something that isn’t even in your commit. This effects my workflow on a daily basis, and I suspect many others too.

Your take on the correct solution to problem. Another linter (but for Python) already implements this feature. I’m not sure how it is implemented, but I would assume it works something like:

• take all files relevant files
• lint them in their entirety
• then only report the lines which are +'d in the diff

There is some nuance here around linting the file on disk, or linting the file as staged.

Ultimately the output of this would be something like

git diff | eslint --diff

Beautiful.

Are you willing to submit a pull request to implement this change? Yeah but I’m gonna need help!

[mdjermanovic]

Hi @cowlicks, thanks for the issue!

I’m confused by the proposal. The problem you want to solve is about linting staged versions instead of local files, but the solution is about showing linting errors only for diff between the local file and git.

Another linter (but for Python) already implements this feature.

This doesn’t look related to staged changes.

• then only report the lines which are +'d in the diff

A changed line can produce linting errors elsewhere, so it doesn’t seem that filtering errors by diff lines would provide much value. For example, renaming a variable in a declaration can produce no-undef and other errors across the file.

[mdjermanovic]

git diff --cached | flake8 --diff

I don’t think that any linter can work on fragments of code, the whole file is needed. How can it get the staged versions from this diff, assuming that the working tree isn’t clean? I believe this still lints file versions from the working tree, just like the gist you mentioned in the original post.