Suggestion

Ever since #6754, we've tested run unit tests for eslint-plugin, eslint-plugin-internal, and typescript-estree both with parserOptions.project and parserOptions.projectService:

Doing so gives us coverage to make sure that rule behaviors don't differ unexpectedly between the two. That coverage was especially useful in the early days of projectService, when we weren't able to be as confident it was an equivalent to project.

However, that double-testing comes with two downsides:

• It adds a lot of extra CI work time: eslint-plugin in particular has a lot of slow tests: see also Repo: Improve CI performance to avoid throttling #11204
• It adds complications to how rules are tested, such as those that need to test specific TSConfig compiler options: see changes in fix(parser): error when both projectService and project are set #11333

Now that projectService has been stable for a while, I'd like to propose we:

• Remove 'eslint-plugin' from the matrix for TYPESCRIPT_ESLINT_PROJECT_SERVICE: true
• Default its rule tests to always use projectService: true by default...
• ...except when they customize the project, in which case they'll stick with project settings

Note that 'eslint-plugin-internal' and 'typescript-estree' would still both be tested with both project and projectService.

What do we think? Is this safe enough to do now / is leaving in project-customized eslint-plugin rule tests + the two other packages enough coverage?

Additional Info

See also #11204 for tracking CI performance improvements.

💖