Type-aware configs

[bmish]

Continuing this discussion:

Originally posted by @JoshuaKGoldberg in #433 (comment)

[bmish]

I'm leaning toward a single type-checked config as likely making the most sense in our case rather than having a type-aware version of every one of our many configs (recommended-type-checked, etc). Perhaps it makes sense for @typescript-eslint which is more focused on types to have type-checked versions of all of their configs, but the same solution for us might be overkill.

Thoughts?

[JoshuaKGoldberg]

Curiosity: what was the motivation for making standalone rules-recommended & tests-recommended configs? I can guess from the names but was there strong user need mentioned anywhere?

[bmish]

I'll have to look back at the PRs that added those configs to see if there was any explanation mentioned for adding them.

However, they are theoretically useful for reducing false positives so we don't mistakenly detect rules or tests in files they shouldn't exist in, and for performance (although this isn't a huge concern in eslint plugins which are usually small).

Either way, I do think it's important to have a solution that can scale regardless of how many configs we have. There are many possible conceivable configs including for stylistic preferences, targeting older versions, etc.

In general, I think there should be a convention for type-aware rule configs that handles plugins with a variety or larger number of configs without causing excess maintenance burden or unnecessarily multiplying the API surface.

[aladdin-add]

Perhaps we could introduce rule.meta.docs.tags to replace rule.meta.docs.category. unlike category, it could be an array. e.g. tags: ["rule"], tags: ["rule", "type-checked"]

The final exported configs can be derived by calculating various combinations of docs.recommended + docs.tags:

• rule+recommended
• rule+type-checked
• ...

The idea originally came from my vision for the rules presentation on the eslint website. The benefit of this approach is that it is highly scalable.