"destructured" option for camelCase rule
See original GitHub issuewhen destructuring an underscore_spaced request:
const { category_id: category } = query;
camelCase errors that category_id
is not in camel case
It would be nice to have a “destructuring” option, or just ignore when destructuring non-camel-case props to camelCase.
Issue Analytics
- State:
- Created 8 years ago
- Comments:10 (6 by maintainers)
Top Results From Across the Web
camelcase - ESLint - Pluggable JavaScript Linter
This rule focuses on using the camelcase approach. ... Please note that this option applies only to identifiers inside destructuring patterns.
Read more >Disable check of camel case rule in eslint
I am trying to disable them and address them one at a time. The code below shows that I can disable them all...
Read more >naming-convention | typescript-eslint
This rule allows you to enforce conventions for any identifier, using granular selectors to create a fine-grained style guide. note. This rule only...
Read more >vue/custom-event-name-casing
This rule aims to warn the custom event names other than the configured casing. (Default is camelCase.) Vue 2 recommends using kebab-case ......
Read more >camelCase in front, snake_case in the back : r/javascript
Indeed, either rename the variables during destructuring, have your deserializer on the front end automatically convert to camel case or ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This still seems to be an issue when destructuring imports, f. ex.:
It is especially problematic as the user has no control over the naming in external libraries.
Since the pattern key is “external” code*, my first reaction is that we should be ignoring that by default, no option necessary. Thoughts?
*If it comes from a response, then it’s truly external. If it comes from an object created elsewhere, camelcase will catch the issue then. Either way, the local variable is what matters.