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
Can't specify object keys that aren't camel case, even when quoted #225
Comments
Very valid point, I ran into this couple of times before. |
The problem is that ESLint rules have no knowledge of each other and the ESLint team doesn't seem interested in solving such problem. We could maybe work around it in XO by checking the results and handle conflicts. |
I've run into this issue once on a module that deals with mysql tables, in the past I just disabled camelcase. I just submitted a PR to eslint for camelcase to have an "exceptions" option with a list of identifiers. I feel like this is within the norm for an eslint rule and honestly it will serve my own needs. As for |
For reference: eslint/eslint#9684
That seems too specific to the underscore style. Maybe it could be an |
/* eslint camelcase: ["error", {properties: "never"}] */
// invalid
const foo_bar = 'baz'
// valid:
const bar = {
foo_bar: fooBar
} |
@j-f1 I don't want to ignore all object keys, just the ones with underscore. |
What’s the difference? |
I assumed the |
I'm not really concerned how it's solved though. I just want a solution to the rule conflict with |
I don’t see one if you set |
Issue fixed. "xo": {
"extends": ".eslintrc"
}, and in {
"rules": {
"camelcase": [
"error",
{ "properties": "never" }
]
}
} The file |
@ideastouch yes of course, that's an option - overriding the default configuration is always an option. But this issue is addressing two conflicting rules in the default XO configuration that don't make sense. |
The quote-props already has exception cases for |
According to the ESLint team, the fact that |
Yep. So not sure that quoting the properties not in camel case, as suggested in the present issue, is the right approach... The best option might to use |
The bugs in the camelcase rule have been fixed and there’s nothing XO can do about allowing some camelcase keys. You can disable the rule globally or inline or, if possible, add some exclusions to the rule’s config. |
It appears I'm going to have to create pragmas to ignore some rules.
With the following object:
XO dies with
However, when quoting it (thinking maybe it would ease the error), it errored out with:
It appears there's no proper way in XO to do this without ignoring some lines (which is ugly).
What XO should do is detect when errors arise in
quote-props
would cause other errors if unquoted and ignore such cases, though I would imagine this would require some hefty plugin code.The text was updated successfully, but these errors were encountered: