[Feature request] Lint only certain lines in a file

My motivation for this feature request is that the same that precise-commits addresses. I want to be able to --fix only the lines that I’ve changed in a source file. precise-commits lays out some of the drawbacks of applying --fix on a particularly large file:

• Increases the complexity and review time burden of PRs on senior team members.
• Potentially increases the amount of time it takes to complete a PR in the first place.
• Can block concurrent work on the same codebase and/or result in nasty merge conflicts with outstanding feature branches.

If I make a change on line 10 of a 4000 line file, I shouldn’t be forced to reformat all 4000s lines (thus making me the last git user to update all of them) as part of my PR. I should just need to reformat line 10.

This may already be possible by splicing changes and passing them to eslint’s --stdin. Either way, consider this request a conversation starter.

[betaorbust]

We would also like this feature, as we’d like to enforce folks fixing/modifying their own changes while not making them fix the entire file. This use case for us is in a large team, with incoming new lint rules, and large files that the engineer might not have all the context on. We don’t want to block their PRs or pushes because everything isn’t perfect, but we’d like to ensure that new/modified code is within our current styles.

[not-an-aardvark]

I’ve had a related use case in the past where I wanted to gradually enable ESLint on a large codebase, but running eslint --fix on the whole codebase (or even fixing problems one rule at a time) was undesirable because it would mess up the git history and cause a lot of merge conflicts. In that case, it would have been useful to have a general heuristic of “Only report problems that weren’t present before this change, or problems that appear on a line that has been changed.” As a result of following this heuristic, the codebase would gradually become more consistent as lines were changed, without interfering with git history.

I’m not sure what the best way to enforce that heuristic is (whether it’s something that should be handled in ESLint core or elsewhere), but hopefully that explains a potential use case.