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.

CodSpeed Performance Report

Merging #8149 will not alter performance

_{Comparing baseballyama:feat/lint/no-negated-condition (68b1863) with main (faf7464)}

Summary

✅ 29 untouched benchmarks

@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?

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

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

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.

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

@camc314

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

I updated the PR according to your comment.
24388b5