Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

naming-convention: constructorVariable #49

Open
Patrik-Lundqvist opened this issue Jan 25, 2018 · 2 comments
Open

naming-convention: constructorVariable #49

Patrik-Lundqvist opened this issue Jan 25, 2018 · 2 comments

Comments

@Patrik-Lundqvist
Copy link

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
@ajafff
Copy link
Owner

ajafff commented Jan 25, 2018

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.

@Patrik-Lundqvist
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants