feat(linter): Implement rule docs and config support for rules with tuple config options.

[connorshea]

This was built out of the ashes of #16555. Implements necessary work for #16023.

This introduces a new TupleRuleConfig. Rather than forcing DefaultRuleConfig to bend to our will as attempted previously, this PR adds a distinct rule config setup that is built to handle tuple-based rule configs.

This PR updates 3 rules to use TupleRuleConfig:

• eslint/eqeqeq
• eslint/sort_keys
• eslint/yoda

It also adds snapshot validation tests to ensure that they error as-expected when given an invalid config option.

The only real change here is in eslint/eqeqeq. We previously allowed passing only an object to the rule config (due to #8790), but that is not valid in the original rule, and also makes implementing proper config option validation quite a bit more difficult. I had removed support for this in #16560, but that was part of the previous, doomed attempt at using DefaultRuleConfig with tuples. So it never got merged, and I'm redoing it here.

This is a necessary part of the change for this PR, as the alternative is to make the config options parsing/validation implementation considerably more complex. This also brings us back in line with ESLint's behavior for this rule.

---

AI Disclosure: I used the code and tests from #16555 as the basis for the changes in rule.rs, then let Claude Opus 4.5 run with it and guided it toward the TupleRuleConfig concept. After I got a satisfactory TupleRuleConfig implementation, I then manually implemented the rest of the changes in this PR by copying the files over from #16555, applying the TupleRuleConfig rename, and then carefully going through the diffs to make sure nothing was deleted that shouldn't have been.

I have added tests to ensure that the config validation for tuple rules works, and have entirely avoided changing the unit tests in any of the 3 modified rules (other than the one change for eqeqeq I noted above).

---

Updated docs for the changed rules

Note that the sort-keys docs are entirely unchanged as they were correct prior to this, so I've excluded them.

yoda:

## Configuration

### The 1st option

type: `"never" | "always"`

#### `"never"`

The default `"never"` option can have exception options in an object literal, via `exceptRange` and `onlyEquality`.

#### `"always"`

The `"always"` option requires that literal values must always come first in comparisons.

### The 2nd option

This option is an object with the following properties:

#### exceptRange

type: `boolean`

default: `false`

If the `"exceptRange"` property is `true`, the rule _allows_ yoda conditions
in range comparisons which are wrapped directly in parentheses, including the
parentheses of an `if` or `while` condition.
A _range_ comparison tests whether a variable is inside or outside the range
between two literal values.

#### onlyEquality

type: `boolean`

default: `false`

If the `"onlyEquality"` property is `true`, the rule reports yoda
conditions _only_ for the equality operators `==` and `===`. The `onlyEquality`
option allows a superset of the exceptions which `exceptRange` allows, thus
both options are not useful together.

eqeqeq:

## Configuration

### The 1st option

type: `"always" | "smart"`

#### `"always"`

Always require triple-equal comparisons, `===`/`!==`.
This is the default.

#### `"smart"`

Allow certain safe comparisons to use `==`/`!=` (`typeof`, literals, nullish).

### The 2nd option

This option is an object with the following properties:

#### null

type: `"always" | "never" | "ignore"`

##### `"always"`

Always require triple-equals when comparing with null, `=== null`/`!== null`.
This is the default.

##### `"never"`

Never require triple-equals when comparing with null, always use `== null`/`!= null`.

##### `"ignore"`

Ignore null comparisons, allow either `== null`/`!= null` or `=== null`/`!== null`.

[Copilot]

Pull request overview

This pull request implements support for tuple-based ESLint rule configurations by introducing a new TupleRuleConfig type. Rather than forcing the existing DefaultRuleConfig to handle tuple configurations, this PR creates a dedicated wrapper that properly deserializes ESLint-style tuple configs like ["option", { "key": "value" }].

Changes:

• Introduced TupleRuleConfig type for handling tuple-based rule configurations with proper validation and error reporting
• Migrated three rules (eslint/eqeqeq, eslint/sort-keys, eslint/yoda) to use the new tuple config system
• Added comprehensive unit tests for both DefaultRuleConfig and TupleRuleConfig deserialization
• Added snapshot tests to validate error messages for invalid tuple configurations

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
crates/oxc_linter/src/rule.rs	Added TupleRuleConfig type and comprehensive tests for config deserialization
crates/oxc_linter/src/rules/eslint/yoda.rs	Refactored to use TupleRuleConfig with enum-based config instead of boolean flags
crates/oxc_linter/src/rules/eslint/sort_keys.rs	Migrated to TupleRuleConfig, removed manual config parsing
crates/oxc_linter/src/rules/eslint/eqeqeq.rs	Migrated to TupleRuleConfig, simplified config struct, removed object-only config support
crates/oxc_linter/tests/rule_configuration_documentation_test.rs	Removed eslint/yoda from the list of rules without schema (now has proper schema)
apps/oxlint/fixtures/valid_complex_config/.oxlintrc.json	Added test cases for the three migrated tuple config rules
apps/oxlint/fixtures/invalid_config_tuple_rules/.oxlintrc.json	Added test fixture with invalid configurations to verify error messages
apps/oxlint/src/snapshots/fixtures__valid_complex_config_@oxlint.snap	Updated snapshot to reflect 3 additional rules with valid configs
apps/oxlint/src/snapshots/fixtures__invalid_config_tuple_rules_@oxlint.snap	New snapshot showing error messages for invalid tuple configurations
apps/oxlint/src/lint.rs	Added test case for invalid tuple rule configurations

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing retry-default-rule-config (5986690) with main (52b5003)¹}

Summary

✅ 4 untouched benchmarks
⏩ 41 skipped benchmarks²

Footnotes

1. No successful run was found on main (ffec86b) during the generation of this report, so 52b5003 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 41 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[Boshen]

Merge activity

• Jan 22, 5:27 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jan 22, 5:27 AM UTC: Boshen added this pull request to the Graphite merge queue.
• Jan 22, 5:33 AM UTC: Merged by the Graphite merge queue.