Repro

{
  "rules": {
    "@typescript-eslint/camelcase": [ "error" ],
  }
}

export class Example {
  public PascalCasedMethod(): void { }
  public convertToHTML(): void { }
  public _______HOWisTHISacceptable______(): void { }
}

Expected Result

A "camel case" identifier starts with a lower case letter, and then uses a capital for the first letter of each word.

For the TSLint rules that I've been migrating, the identifier PascalCasedMethod would be forbidden because it is not camel case. It should be changed to pascalCasedMethod.

We would also forbid the identifier convertToHTML, instead preferring convertToHtml in camel case.

I don't know how to describe _______HOWisTHISacceptable______, but it's clearly not camel case.

Actual Result

The @typescript-eslint/camelcase rule accepts all of the above identifiers. No errors are reported. Recently I saw a PR where someone created a Pascal-cased method.

From what I can tell, the rule implementation doesn't consider camel case at all. It merely bans snake_case by checking whether an underscore appears between any letters.

Additional Info

This problem also affects the base ESLint rule. It was brought up a long time ago as eslint/eslint#10473. In that thread, they note that JavaScript has trouble distinguishing a camelCase member from a PascalCase constructor function.

We could fix it in ESLint, but I see a few reasons why we might instead want to tackle this problem in @typescript-eslint/eslint-plugin:

• This plugin has a goal to replace TSLint, whose variable-name does not allow PascalCase or extra underscores
• Unlike JavaScript, the constructor function casing concern is irrelevant to TypeScript
• The @typescript-eslint/camelcase extension has a fair amount of extra logic, so we'd likely have to modify it regardless of whether we fixed ESLint or not

The fix should be pretty easy, and would involve adding a new option (e.g. strict: true) that changes the rule to actually test for camel case. Or, if we want to be very flexible, the option could require the identifier MUST match one of the RegExps from the allow option. That would give custom configurations a lot of freedom for allowing/disallowing edge cases, while keeping the rule simple to understand.

In the eslint/eslint#10473 discussion, they pointed out that ESLint's id-match rule can be used to solve this problem. I'm open to that approach as well, however we'd have to extend that rule for @typescript-eslint/eslint-plugin and reimplement all the logic that's currently in camelCase. That seems less desirable to me, since (for myself at least) I want the error message to say "you're not using camel case" rather than saying "PLEASE COMPLY WITH ON OF THESE CRYPTIC REGEXPS".

Versions