refactor(linter/plugins): refactor config merging in RuleTester#16657
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
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. |
There was a problem hiding this comment.
Pull request overview
This PR refactors config merging in RuleTester to simplify the handling of three-level configuration (default, instance, and test case). Instead of passing config separately through multiple function layers, configs are now merged directly into each test case object at the start of test execution, making the data flow more straightforward.
Key Changes:
- Removed index signature
[key: string]: unknownfromConfiginterface for stricter typing - Made
TestCaseinterface extendConfigto allow test cases to have config properties - Refactored config merging to happen once per test case via
mergeConfigIntoTestCase()instead of repeatedly through function chains - Added
TEST_CASE_PROP_KEYSset to filter test-case-specific properties during config merging, including"__proto__"for security
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| apps/oxlint/test/rule_tester.test.ts | Updated tests to use actual config property eslintCompat instead of arbitrary whatever property, reflecting stricter Config interface typing |
| apps/oxlint/src-js/package/rule_tester.ts | Core refactoring: removed index signature from Config, added config filtering logic, merged config into test cases early in execution flow, updated function signatures accordingly |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Merge activity
|
…6657) `RuleTester` has 3 levels of config: 1. Default config - set with `RuleTester.setDefaultConfig(...)`. 2. `RuleTester` instance config - set with `new RuleTester(...)`. 3. Config set on individual test cases. Simplify handling all this by merging configs into each `TestCase`, so that `TestCase` contains all the properties for an individual test - regardless of at what level they were set.
18e615d to
eb9f814
Compare
…6657) `RuleTester` has 3 levels of config: 1. Default config - set with `RuleTester.setDefaultConfig(...)`. 2. `RuleTester` instance config - set with `new RuleTester(...)`. 3. Config set on individual test cases. Simplify handling all this by merging configs into each `TestCase`, so that `TestCase` contains all the properties for an individual test - regardless of at what level they were set.
…c-project#16657) `RuleTester` has 3 levels of config: 1. Default config - set with `RuleTester.setDefaultConfig(...)`. 2. `RuleTester` instance config - set with `new RuleTester(...)`. 3. Config set on individual test cases. Simplify handling all this by merging configs into each `TestCase`, so that `TestCase` contains all the properties for an individual test - regardless of at what level they were set.

RuleTesterhas 3 levels of config:RuleTester.setDefaultConfig(...).RuleTesterinstance config - set withnew RuleTester(...).Simplify handling all this by merging configs into each
TestCase, so thatTestCasecontains all the properties for an individual test - regardless of at what level they were set.