refactor(linter/plugins): store rule options as Vecs

[overlookmotel]

Follow-on after #16215.

Options for each rule is always an array. Enforce this in type system by storing options as Vec<serde_json::Value> instead of a single serde_json::Value which is always a Value::Array.

I'll try to alter ESLintRule's config field to be a Vec<serde_json::Value> too in another PR to follow.

[overlookmotel]

• refactor(linter): rename RuleEnum::read_json to from_configuration #16340 : 2 dependent PRs (#16347 , #16350 )
• perf(linter): avoid cloning rule options #16338
• refactor(linter/plugins): store rule options as Vecs #16336 👈 (View in Graphite)
• main

---

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.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Copilot]

Pull request overview

This PR refactors the ExternalPluginStore to enforce that rule options are always arrays at the type system level. Instead of storing options as serde_json::Value (which would always be a Value::Array), they are now stored as Vec<serde_json::Value>, making the invariant explicit in the type system.

Key changes:

• Changed the options field type from IndexVec<ExternalOptionsId, serde_json::Value> to IndexVec<ExternalOptionsId, Vec<serde_json::Value>>
• Updated add_options to destructure the array at runtime and panic if it's not an array
• Simplified initialization to use vec![] instead of serde_json::json!([])

---

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

[codspeed-hq]

CodSpeed Performance Report

Merging #16336 will not alter performance

_{Comparing 12-01-refactor_linter_plugins_store_rule_options_as_vec_s (d7a4296) with main (5ad5435)¹}

Summary

✅ 4 untouched
⏩ 41 skipped²

Footnotes

1. No successful run was found on main (55cf157) during the generation of this report, so 5ad5435 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. ↩

[overlookmotel]

Merge activity

• Dec 1, 1:44 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Dec 1, 1:44 PM UTC: overlookmotel added this pull request to the Graphite merge queue.
• Dec 1, 1:50 PM UTC: Merged by the Graphite merge queue.

[camc314]

can this ever be more than a single element? maybe it should be a custom type with a custom serialize implementation, this means we could reduce memory usage as we wouldn't have to keep the vec wrapper

[overlookmotel]

Certainly for JS plugins it can be more then 1 element long. This is legit:

{
  "rules": {
    "my-rule": ["error", "something", 123, false, { "oh yeah": true } ]
  }
}

...and I believe many real rules do take multiple options like this.