You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If you have strict and lenient as true in the config file, a fatalError will be thrown, but either can be overridden by the --strict or --lenient command line options, and they will also override the opposite setting in the config file.
For example, if you have
lenient: true in your config file, but you specify --strict on the command line, you will get the strict behaviour, and your config file setting will be ignored.
I tested this manually - it was hard to do a unit test, because we fatalError instead of throwing an error right now.
As before, --strict and --lenient on the command line will also fatal error.
The options turn more and more complex. It'd be really useful to have the combinations tested.
Did you have anything particular in mind - it would be quite easy to expose the logic in applyLeniency for the interactions between command line and config options, or are you thinking of something more.
The options turn more and more complex. It'd be really useful to have the combinations tested.
Did you have anything particular in mind - it would be quite easy to expose the logic in applyLeniency for the interactions between command line and config options, or are you thinking of something more.
Not sure if it's clean to move applyLeniency into LintOrAnalyzeOptions. In there, it would naturally be internal and can thus be tested.
The options turn more and more complex. It'd be really useful to have the combinations tested.
Did you have anything particular in mind - it would be quite easy to expose the logic in applyLeniency for the interactions between command line and config options, or are you thinking of something more.
Not sure if it's clean to move applyLeniency into LintOrAnalyzeOptions. In there, it would naturally be internal and can thus be tested.
Something like this perhaps, which tests the logic, if not the actual violations mapping?
extension LintOrAnalyzeOptions {
// config file settings can be overridden by either `--strict` or `--lenient` command line options
func leniency(strict: Bool, lenient: Bool) -> (Bool , Bool) {
let strict = (strict && !self.lenient) || self.strict
let lenient = (lenient && !self.strict) || self.lenient
return (strict, lenient)
}
}
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.
mildm8nnered
force-pushed
the
mildm8nnered-add-lenient-option-to-config-file
branch
from
Addresses #5779
So I basically just copied #5226 (which I wrote).
If you have
strictandlenientas true in the config file, afatalErrorwill be thrown, but either can be overridden by the--strictor--lenientcommand line options, and they will also override the opposite setting in the config file.For example, if you have
lenient: truein your config file, but you specify--stricton the command line, you will get thestrictbehaviour, and your config file setting will be ignored.I tested this manually - it was hard to do a unit test, because we
fatalErrorinstead of throwing an error right now.As before,
--strictand--lenienton the command line will also fatal error.