Introduce a maxwarning option. To accompany the maxerr option.

[jhicken]

#3562 Introduced some new issues. I have a situation where I have potentially an unlimited number of warnings. And I would like to stop collecting warnings at somepoint. Before #3562 I was using the maxerr option. Could we consider implementing a maxwarning option.

[jugglinmike]

Yes, I'm certainly open to discussing that!

Something I mentioned in gh-3444 (the feature request which precipiated the change) seems relevant here:

Errors describe problems in parsing, so they often appear in large numbers following a single syntax error. That's because JSHint attempts to recover from invalid syntax as a convenience to the user. Recovery involves some guesswork, so there's no foolproof way to do it. If JSHint guesses incorrectly, then it will end up reporting a large number of irrelevant errors.

Warnings, on the other hand, are reported in response to discrete patterns in the code. They're far less likely to exhibit the same kind of "avalanche" that sometimes occurs for errors.

This makes me wonder: are each of the warnings that you are seeing distinct? What is it that makes some more important than others?

[jhicken]

Are each of the warnings that you are seeing distinct? Yes? maybe? I'll try and answer this. Let me know if you are asking for something different though.
So in this situation a user is using a code editor in our app. And said user is potentially entering in minified code. (I know this sounds really silly but it makes sense in our case). Sometimes due to the minified code, we end up with things like a = new Date throwing warnings. These warnings are very individualized to their own cause. Totally understandable and good, but when you have thousands of these individual warnings it can be painful and slow to let the linter keep chewing cpu cycles. This also slows down our test suit pretty dramatically. I figure in this case if the user has this many warnings they probably don't really care to fix them. So I would like to limit the cpu waisted on them.

What is it that makes some more important than others? The case I described above hopefully gives some more context. It's not that any warning is more valuable than another. It's just the ability to limit cpu usage in this case.

[jugglinmike]

Got it. That's a pretty rarefied use case, but I can see how you can't really work around it without explicit support from JSHint.

Implementing a maxwarning option shouldn't take too much code. Do you have any interest in writing a patch?