[naming-convention] Handle names that are a classish type

[sindresorhus]

{
	rules: {
		'@typescript-eslint/naming-convention': [
			'error',
			{
				selector: 'default',
				format: [
					'strictCamelCase'
				],
				leadingUnderscore: 'allow',
				trailingUnderscore: 'allow'
			}
		}
	}
}

export interface Got extends GotFunctions {
	GotError: typeof errors.GotError;
	CacheError: typeof errors.CacheError;
	RequestError: typeof errors.RequestError;
	ReadError: typeof errors.ReadError;
	ParseError: typeof errors.ParseError;
	HTTPError: typeof errors.HTTPError;
	MaxRedirectsError: typeof errors.MaxRedirectsError;
	UnsupportedProtocolError: typeof errors.UnsupportedProtocolError;
	TimeoutError: typeof errors.TimeoutError;
	CancelError: typeof errors.CancelError;
}

export const Chalk: new (options?: Options) => ChalkInstance;

Expected Result

In the above example, errors.GotError and the other properties refers to a class, so GotError has to be PascalCase. However, I couldn't find a way to target properties that are classes.

Actual Result

  ✖   60:2   Property name GotError must match one of the following formats: strictCamelCase                         @typescript-eslint/naming-convention
  ✖   61:2   Property name CacheError must match one of the following formats: strictCamelCase                       @typescript-eslint/naming-convention
  ✖   62:2   Property name RequestError must match one of the following formats: strictCamelCase                     @typescript-eslint/naming-convention
  ✖   63:2   Property name ReadError must match one of the following formats: strictCamelCase                        @typescript-eslint/naming-convention
  ✖   64:2   Property name ParseError must match one of the following formats: strictCamelCase                       @typescript-eslint/naming-convention
  ✖   65:2   Property name HTTPError must match one of the following formats: strictCamelCase                        @typescript-eslint/naming-convention
  ✖   66:2   Property name MaxRedirectsError must match one of the following formats: strictCamelCase                @typescript-eslint/naming-convention
  ✖   67:2   Property name UnsupportedProtocolError must match one of the following formats: strictCamelCase         @typescript-eslint/naming-convention
  ✖   68:2   Property name TimeoutError must match one of the following formats: strictCamelCase                     @typescript-eslint/naming-convention
  ✖   69:2   Property name CancelError must match one of the following formats: strictCamelCase                      @typescript-eslint/naming-convention

Additional Info

Versions

package	version
@typescript-eslint/eslint-plugin	2.17.0
@typescript-eslint/parser	2.17.0
TypeScript	3.7.5
ESLint	6.8.0
node	10.17.0
npm	6.13.6

[bradzacher]

See: #1484 (comment)

[ab-pm]

Also useful when aliasing classes (const A = class B { … }). The convention that constructors, and only constructors, should be named in pascal case, is absolutely standard in the JS ecosystem. I was really surprised that one cannot build a rule to enforce this - the types selector is predestined for this!
Once this is implemented, it imo should become part of the default rules.

(On a related note, it would be cool to have even more control over the types selector to e.g. match types of factory functions, but that's feature creep. All I want now is the distinction between constructors and ordinary functions).

[karlhorky]

Another use case is dynamic imports:

// ❌ Variable name `Stripe` must match one of the following formats: camelCase eslint(@typescript-eslint/naming-convention)
const { Stripe } = await import('stripe');

No problems with static imports:

import { Stripe } from 'stripe';

[fedorov-xyz]

@bradzacher, hello. When is it roughly planned to implement this?

[bradzacher]

We are a community run project. The issues that get worked on are the issues the community wants to work on.

The volunteer maintainers spend most of their time on repo maintenance and framework improvements.

So the answer is "it's planned for never, unless the community wants it done sooner"

[JoshuaKGoldberg]

Per #8792, we're feature freezing this rule. It's reached the point of complexity where we're having a hard time justifying working on it.

If you'd like to see this option happen, I'd encourage you to add it to a community project such as eslint.style. Cheers! 💙