Allow result override

[kasparsd]

Currently there is no way to limit linting to only parts of code. This would be really helpful for legacy projects where coding standards are implemented in chunks instead of rewriting the whole files.

A simple solution is to allow the reporter to override the results array:

jshint/src/cli.js

Line 673 in badc7a4

(opts.reporter || defReporter)(results, data, { verbose: opts.verbose });

For example, a custom reporter could use the git diff range for the currently staged changes and use that to remove all JSHint errors that don't apply to that changeset.

[jugglinmike]

This functionality goes beyond typical expectations for "reporting", so I don't
think it would be appropriate to extend the functionality in that way. We could
address your use case with a "results interpreter" API which had free reign to
do whatever it wished with the results array. Or we could restrict the surface
area to what seems to be the minimal requirement: a list of lines to ignore.
Somewhere in the middle would be support for specifying a JavaScript function
that would be used in an Array.prototype.filter operation.

I can appreciate the desire, but I'd like to see a bit more interest from
consumers before moving on this.

In the mean time, you can use JSHint to do what you're looking for today.
Either filter the output of the default reporter according to your criteria, or (edit: I've rescinded this particular approach--see below)
define a custom reporter that only reports the errors/warnings that you're
interested in. In both cases, you'll have to ignore the exit status of the
JSHint process and instead react to the output stream. That's clearly not
ideal, though, which is why I'm not suggesting that a new feature is
unnecessary.

[kasparsd]

Thanks for looking into this @jugglinmike -- agreed 100%!

Using a dedicated API is definitely the right way to implement this. Let's see if others would also find this useful.

[jugglinmike]

My pleasure!

Also: I'd like to rescind my recommendation to parse the output of JSHint's
default reporter. That output is not intended for programmatic consumption and
is subject to change between releases. For folks that are interested in
simulating this functionality on their own, a custom reporter is a far more
stable solution.