camelcase: false positive on interface properties

[bradzacher]

What version of TypeScript are you using? 2.9.1

What version of typescript-eslint-parser are you using? 16.0.0

What code were you trying to parse?

/* eslint camelcase: ['error', { properties: 'never' }] */

interface Foo {
    bar_baz ?: string
}

What did you expect to happen? the interface property passes fine

What happened? [eslint] Identifier 'bar_baz' is not in camel case. (camelcase)

[bradzacher]

I've dug into the codebase a little bit.

typescript-eslint-parser outputs an interface's property as the following AST:

```JSON { "type": "TSPropertySignature", "range": [ 16, 29 ], "loc": { "start": { "line": 1, "column": 16 }, "end": { "line": 1, "column": 29 } }, "computed": false, "key": { "type": "Identifier", "range": [ 16, 19 ], "loc": { "start": { "line": 1, "column": 16 }, "end": { "line": 1, "column": 19 } }, "name": "bar" }, "typeAnnotation": { "type": "TSTypeAnnotation", "loc": { "start": { "line": 1, "column": 20 }, "end": { "line": 1, "column": 28 } }, "range": [ 20, 28 ], "typeAnnotation": { "type": "TSStringKeyword", "range": [ 22, 28 ], "loc": { "start": { "line": 1, "column": 22 }, "end": { "line": 1, "column": 28 } } } } } ```

Which is ace. Note that the property's key is output with type Identifier. The camelcase rule specifically operates on Identifier nodes

Running through the rule definition, they have an if which applies different logic for the Identifier based on different parent types. If the Identifier's parent matches non of those types, then it just straight up checks if it has underscores and reports.

So this is the problem I think. Our parent type is TSPropertySignature, the nearest match for the eslint nodes would probably be Property.

Sooooo.. Correct me if I'm wrong - but based on my understanding of how this parser is intended to work...

• We want to identify the interface properties uniquely, with their own node types.
• We can't add extra logic to eslint's camelcase rule to handle our special node type.

So I really see two solutions. 1) Create a new special TSIdentifier (or similar) type so that base eslint rules won't match against them.

• Might be undesirable? Then base rules can never match against it. 2) Create a new rule needs in eslint-plugin-typescript which extends the base rule to add handling for TSxx specific node types.

[bradzacher]

• not a parser issue
• fixed in plugin in https://github.com/bradzacher/eslint-plugin-typescript/pull/183