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
camelcase with optional chaining #13093
Comments
@RyanPWalker We're currently blocked by this discussion. Once the ESTree maintainers decide how to move forward, Acorn (our underlying parser) will be able to implement this syntax and we'll be able to use this downstream. |
In the interim, assuming that you're using babel, you can use https://github.com/babel/eslint-plugin-babel with the same args for "babel/camelcase" as you would for "camelcase":
|
Any other workaround? Example: My eslint setup:
Any other workaround available? |
I think you should also disable the core
|
thank you!!! disabling core works. |
Seems estree/estree#204 is merged now, but this issue still exists in the latest eslint release |
The core The rule still doesn't work well with the current version of This should be fixed in the next |
Optional chaining is now fully supported in ESLint core and the rule is working as expected, so closing. |
Can confirm, error no longer shows up on latest eslint. Thanks. |
I'm really not sure if this is a bug fix or rule change, but when using optional chaining on an object's keys, I would expect camelcase to not apply. For example, we can't control the data we are given from apis so if they use something that's not camelcase, then it is what it is. So accessing
data?.some_data
should not throw an error.Node version: v12.16.0
npm version: v6.13.4
lint version: ^6.8.0
babel-eslint version: ^10.1.0
The text was updated successfully, but these errors were encountered: