[camelcase] false positive when parsing object pattern with a default value, and using a non-default parser.

Tell us about your environment

• ESLint Version: 6.7.0
• Node Version: 12

What parser (default, Babel-ESLint, etc.) are you using? default, typescript-eslint

Please show your full configuration:

Configuration

{
  rules: {
    camelcase: ['error', {
      "properties": "never",
      "ignoreDestructuring": true
    }],
  },
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

Context: https://github.com/typescript-eslint/typescript-eslint/issues/1686 A user of typescript-eslint received a linting error with the following code, even though it should be covered by the options above.

  const res = {a_b:123}
  const {a_b=0} = res
//       ^^^ Error Identifier 'a_b' is not in camel case

This error occurs when parsing with typescript-eslint, and not with the default parser. Thinking this was a bug in the typescript-eslint parser, I did some digging, and it turns out that the acorn reuses the AST node in two places (i.e. the two a_b Identifiers are referentially equal). https://github.com/acornjs/acorn/issues/928

This causes the parent references to be set incorrectly, as the node’s parent will be that of whichever node was traversed last.

Logging this here because:

• the rule doesn’t work with the “correct” parent pointers,
• the rule will have to be updated for when the bug in acorn is fixed.

[mdjermanovic]

Actually, #12831 seems to work well by chance. The name of the function isRenamedImport is wrong if parser always creates two nodes, but the code inside works okay and prevents reporting the same location twice.

It is, however, difficult to think about and cover both variations with same code.

[mdjermanovic]

Then, I misread the estree spec while working on #12831 so we should probably fix that as well. Tests didn’t catch it because acorn creates just 1 node.

I was sure it’s the same node because there is no something like shorthand attribute, so it isn’t possible to distinguish between import { a } from "foo" and import { a as a } from "foo" without comparing locations.