Something we've avoided in our project is rules that conditionally use type information.

The reason we have avoided them historically them is because:
A) in most cases there's no reason someone wouldnt want the extra safety from the type-information.
B) there's a lot of config complexity that gets added from this because the user needs to understand that "turning on config option X requires you to setup type-aware linting".

There's currently just one rule in our project that uses conditional type infonaming-convention which uses types if and only if the user configures a selector that checks types. Which was only added because users wanted to be able to configure specific names for boolean-typed variables.

I do wonder if we're unnecessarily tying our hands with this restriction. Whilst it's true that most cases you just want the type-aware checks and that without type-information a rule will be buggy or incomplete, there are cases where some users might want to opt-in to additional checks in specific circumstances or type-aware fixers.

Two quick examples off the top of my head:

• explicit-function-return-type/explicit-module-boundary-types could have a type-aware suggestion fixer added conditionally to help people annotate functions using the inferred return types, or even an autofixer for some simpler cases (like primitives -string,number,boolean,void).
• feat(eslint-plugin): [no-mixed-enums] add rule #6102no-mixed-enums could be AST-based by default, and have an option to be type-aware if the user's codebase uses enum merging or derived enums (both of which are rarer cases).
• feat(eslint-plugin): [prefer-optional-chain] use type checking for strict falsiness #6240prefer-optional-chain is currently AST based - but there are some edge cases with the boolean logicals that may refine a boolean type out that need type information to catch. It's a rarer case so it could be the case that this can be an opt-in.

Now that we're a more mature project, I think we're getting to the point where our users are well-versed enough to understand the nuances of this style.

I'd be interested in us speccing this out a bit if people agree it's a good idea:

• How should we document it? We'll want a standard form of documentation in the rule docs and rule table to make it consistent and clear.
• Should we do anything special with the config to make it clear when users are configuring that they're about to opt-in to type-info (or opt-out if we choose to allow less safety?)