It might be useful to have some Suggestions in the core rules, as a working example for rule plugins and a ready test for editor integrations? This rule looks to me like a place where suggestions make sense and should be simple enough to implement for the start.
What rule do you want to change?
no-unsafe-negation
Does this change cause the rule to produce more or fewer warnings?
same
How will the change be implemented? (New option, new default behavior, etc.)?
new default behavior
Please provide some example code that this change will affect:
/*eslint no-unsafe-negation: "error"*/
if (!key in object) {
// ...
}What does the rule currently do for this code?
Just an error without the autofix. The fixer was recently removed in #12157 because it was changing behavior.
What will the rule do after it's changed?
An error with two suggestions.
The first suggestion would be to negate the whole relational expression. This changes behavior, but probably from a bug to the intended one (that's how the removed fixer was working):
/*eslint no-unsafe-negation: "error"*/
if (!(key in object)) {
// ...
}The second suggestion would be to make the existing intended behavior explicit, by wrapping the negation in parentheses, which is a documented exception allowed by this rule and does not produce an error after the fix:
/*eslint no-unsafe-negation: "error"*/
if ((!key) in object) {
// ...
}Does this make sense?
Are you willing to submit a pull request to implement this change?
Yes.
It might be useful to have some Suggestions in the core rules, as a working example for rule plugins and a ready test for editor integrations? This rule looks to me like a place where suggestions make sense and should be simple enough to implement for the start.
What rule do you want to change?
no-unsafe-negationDoes this change cause the rule to produce more or fewer warnings?
same
How will the change be implemented? (New option, new default behavior, etc.)?
new default behavior
Please provide some example code that this change will affect:
What does the rule currently do for this code?
Just an error without the autofix. The fixer was recently removed in #12157 because it was changing behavior.
What will the rule do after it's changed?
An error with two suggestions.
The first suggestion would be to negate the whole relational expression. This changes behavior, but probably from a bug to the intended one (that's how the removed fixer was working):
The second suggestion would be to make the existing intended behavior explicit, by wrapping the negation in parentheses, which is a documented exception allowed by this rule and does not produce an error after the fix:
Does this make sense?
Are you willing to submit a pull request to implement this change?
Yes.