Add '--fail_on_warnings', issue #3451 #4124
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds option
--fail_on_warnings
as requested in #3451 (and that I missed myself too). It is obviously not finished, but before adding documentations, tests, etc. I'd like to see some feedback if this option is fine in general.Instead of meddling with existing warning guards as suggested by brad4d in the issue, I decided to keep a simple boolean flag and at the last possible point check it: if we still have a warning level by then, simply turn it into an error. I feel it is cleaner this way (and also easier, yeah), because configuration of warning guards (which is quite extensive, with all the different named categories) is completely independ from "fail on warnings" setting and you don't need to coordinate changes in them anywhere. In effect, the "fail on warnings" setting is simple "whatever I want as warnings usually, should become an error in this context" and is not dependent on how you set that "whatever" — be that the defaults or extensive custom configuration.
A possible improvement would be to pass to error reporter a boolean "error elevated from warning" so that it could report that if it so chooses.
I verified that it does produce the desired change:
Where
~/test/test.js
is: