feat(linter): implement no-negated-condition rule

[baseballyama]

implement: https://eslint.org/docs/latest/rules/no-negated-condition

[graphite-app]

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[codspeed-hq]

CodSpeed Performance Report

Merging #8149 will not alter performance

_{Comparing baseballyama:feat/lint/no-negated-condition (0cdc22e) with main (5234d96)}

Summary

✅ 29 untouched benchmarks

[Sysix]

thanks for the work. I commented some possible improvements.
They are all probably only nitpicking :')

[Sysix]

👍 you can resolve the discussions (I do not have the rights for that ^^)

[camc314]

i think we've already got this rule covered by the unicorn variant?

do you mind porting the test cases to there and seeing if the all pass correctly?

https://github.com/oxc-project/oxc/blob/bd0693bcd01cc826a4717779558e06ce99262732/crates/oxc_linter/src/rules/unicorn/no_negated_condition.rs#L0-L1

[baseballyama]

@camc314

I added tests to the unicorn's rule, and they all passed.
I think it would be better to have a rule on the ESLint side as well, so I rewrote it to forward the processing.
What do you think?

[Sysix]

@camc314 personally I like this remapping. Can we do this the same for other rules and maybe fix #8009 ?

[camc314]

i haven't looked into #8009.

but we shouldn't have the same code doing the same thing/

That said, it would be OK to map unicorn/no-negated-condition to eslint/no-negated-condition as we do for some of the TS rules.

To clarify, we would change the following

oxc/crates/oxc_linter/src/config/rules.rs

Lines 159 to 161 in 3858221

	if plugin_name == "typescript" && is_eslint_rule_adapted_to_typescript(rule_name) {
	return (rule_name, "eslint");
	}

to be something like:

diff --git a/crates/oxc_linter/src/config/rules.rs b/crates/oxc_linter/src/config/rules.rs
index e661f876f..251026b5f 100644
--- a/crates/oxc_linter/src/config/rules.rs
+++ b/crates/oxc_linter/src/config/rules.rs
@@ -160,6 +160,10 @@ fn transform_rule_and_plugin_name<'a>(
         return (rule_name, "eslint");
     }
 
+    if plugin_name == "unicorn" && rule_name == "no-negated-condition" {
+        return ("no-negated-condition", "eslint");
+    }
+
     (rule_name, plugin_name)
 }

that way, regardsless of whether you have eslint/no-negated-condition OR no-negated-condition OR unicorn/no-negated-condition, it should turn on the rule correctly.

[camc314]

i looked into #8009 briefly and i'm pretty sure it's unrelated to this. it's (possibly - although i couldn't reproduce it) a bug somewhere in our config code

[baseballyama]

@camc314

Thank you for your review! (And other PRs also!)

I updated the PR according to your comment.
24388b5