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] allow treating quoted properties differently #2761
Comments
Originally the problem with solving this was that it's actually a really, really, really difficult thing to catch 100% of the time because the rules for what is a valid "identifier" in JS is very, very complicated. However since then, we learned that (thankfully) TypeScript exposes its functions which let it do this check, and we have got a usage of it this in the plugin: typescript-eslint/packages/eslint-plugin/src/rules/switch-exhaustiveness-check.ts Lines 37 to 53 in 98ab010
What solution would I accept for this rule?I would be happy to accept a modifier for the Why a modifier which detects required quotes vs a selector that matches any quoted name? I don't agree that all quoted names should ever just be ignored. A modifier that only is applied when quotes are required allows you to choose to ignore these property names specifically, because they're clearly written this way on purpose. |
This is essentially a duplicate of #1483, which unfortunately was closed without a complete solution.
We have a large code base that used the camelCase rule. We have the convention that whenever objects are used as key-value dictionaries not as records, properties would be quoted (string literal instead of identifier syntax). The camelCase rule would not complain about snake_case or PascalCase property names then. This is used in a lot of places (custom headers, database access layer, application-specific logic, external protocols, and more…) so that whitelisting allowed names is not an option.
Since we don't want to get rid of identifier linting completely, and cannot achieve the desired behavior with the naming-convention rule, we're currently blocked from upgrading typescript-eslint - very dissatisfying.
I'm not suggesting to just add a
ignoreStringKeys
option or even to enable it by default.What is needed is a new
selector
to distinguish properties that are IdentifierNames from properties that are StringLiterals. For completeness, a third category might match properties that are NumericLiterals. I imagine this as an extension topropertyDefinition
from #2244 (comment), which would become a group selector itself.However, this could actually be a separate dimension for the matcher, like
modifiers
andtypes
. While for my concrete use case the distinction is only necessary in object literals (not interface/class member declarations) and not (rarely, actually) for methods, it would provide more flexibility. What do you think?The text was updated successfully, but these errors were encountered: