ajafff/tslint-consistent-codestyle

naming-convention: constructorVariable

Patrik-Lundqvist opened this issue · 2 comments

What do you think of adding a new selector to the naming-convention rule which applies to variables that are containing a construct signature?

With the current selectors I cannot target my redux connected components which has to be written in PascalCase, while keeping non-class containing variables in camelCase.

Current behaviour

Config:

{"type": "variable", "format": ["camelCase"]}

Code:

// connect returns a react component class
const PascalCaseComponent1 = connect(..)(SomeComponent);
const camelCaseComponent2 = connect(..)(SomeComponent);

Result:

PascalCaseComponent1: variable name must be in camelCase

Desired behaviour

Config:

{"type": "variable", "format": ["camelCase"]}
{"type": "constructorVariable", "format": ["PascalCase"]}

Code:

// connect returns a react component class
const PascalCaseComponent1 = connect(..)(SomeComponent);
const camelCaseComponent2 = connect(..)(SomeComponent);

Result:

camelCaseComponent2: variable name must be in PascalCase

I would really like to add this new option. I also had the need for this recently.

Unfortunately this rule does not use (or require) type information. That means the rule could only detect classes that are directly assigned:

const MyConstructor = class {};
const MyOtherConstructorVariable = MyConstructor; // would be invalid

Everything else cannot be detected reliable. That's also how functionVariable works right now.

Making this rule a typed rule would be a breaking change. If you type information is not available (e.g. in VSCode extension) the variable is treated like a regular variable. And when type information is available (e.g. running TSLint from CLI in your CI) the variable is correctly recognized as constructorVariable and other naming rules apply. Therefore you have inconsistencies between execution environments.

Marking this as "revisit" for a future major version of the package.

Ah, I see! Using type information could make this rule really powerful so I'll be looking forward to a new major version. I appreciate the solid work you've done in this package, great stuff!