The following Linter.Config properties maybe should also be excluded:

• linterOptions: this would only make sense for rules for inline configuration
• plugins: only if we want to address a language or processor by its name instead of passing it in directly
• rules: we want to test the rule in isolation (an edge case would be rules which have a side-effect like context.markVariableAsUsed)

I’m fine with excluding linterOptions, plugins, and rules as well, but would like @fasttime’s opinion on this.

All config object keys can be also used in test cases. Excluding some of them from the typings is more a philosophical matter than a technical one. Now, linterOptions, plugins, and rules are not currently included in ValidTestCase, so I think we shouldn't add them if the team has any reservations. That said, I'd be in favor of including them if users request them for a specific use case at some point.

Recently we decided to make the typings of data stricter in eslint/rewrite#310 even though other values (e.g. objects) can be stringified without error and there is no runtime check for this.
IIRC these properties were not allowed to be set in test cases before the introduction of the "flat" config.

IIRC these properties were not allowed to be set in test cases before the introduction of the "flat" config.

linterOptions is a new option in flat config, so it was not allowed in test cases with the old RuleTester in ESLint v8. By contrast, plugins was allowed as an array of strings, and rules, in its current format, was already allowed prior to flat config. I checked the v8 code, and it looks like RuleTester has always worked the same way: moving all non-test-case properties to a config object, and using that config (after validation) to lint the provided code:

You are right. I think I thought that because I never saw those properties in rule test files.