Repro

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

exportclassExample{publicPascalCasedMethod():void{}publicconvertToHTML():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 identifierPascalCasedMethod would be forbidden because it is not camel case. It should be changed topascalCasedMethod.

We would also forbid the identifierconvertToHTML, instead preferringconvertToHtml 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 banssnake_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 aseslint/eslint#10473. In that thread, they note that JavaScript has trouble distinguishing acamelCase member from aPascalCase 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, whosevariable-name does not allowPascalCase 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 theallow option. That would give custom configurations a lot of freedom for allowing/disallowing edge cases, while keeping the rule simple to understand.

In theeslint/eslint#10473 discussion, they pointed out that ESLint'sid-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 incamelCase. 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