Broken eslint rule configuration for typescript with CRA 3.*

Created by: olee

Using create-react-app version 3.* with typescript breaks compilation on certain linting rules and even crashes in some cases. The reason for that is an incorrect eslint rule configuration which is not compatible with https://github.com/typescript-eslint/typescript-eslint

Case 1

Using an overloaded constructor definition in a typescript class like will throw an exception from eslint:

class Case1 {
    constructor(a: number, b: string);
    constructor(b: string);
    constructor(aOrB: string | number, b?: string) {
        if (typeof aOrB === 'number') {
            console.log('variant 1 called with b = ' + b);
        } else {
            console.log('variant 2 called with b = ' + aOrB);
        }
    }
}

Result

eslint will throw the following exception:

TypeError: Cannot read property 'body' of null
Occurred while linting <my test file>
    at Array.forEach (<anonymous>)
    at Array.forEach (<anonymous>)
    at Array.map (<anonymous>)

Solution

This issue was reported here https://github.com/typescript-eslint/typescript-eslint/issues/420 The solution to this problem is to disable no-useless-constructor and enable @typescript-eslint/no-useless-constructor

Case 2

Using an overloaded class method generates invalid warnings from eslint

Example:

class Case2 {
    public test(a: number, b: string): void;
    public test(b: string): void;
    public test(aOrB: string | number, b?: string): void {
        if (typeof aOrB === 'number') {
            console.log('variant 1 called with b = ' + b);
        } else {
            console.log('variant 2 called with b = ' + aOrB);
        }
    }
}

Result

  Line 3:  Duplicate name 'test'                     no-dupe-class-members
  Line 4:  Duplicate name 'test'                     no-dupe-class-members

Solution

The rule no-dupe-class-members should be disabled for typescript linting because typescript compiler already does that: https://github.com/typescript-eslint/typescript-eslint/issues/291

Notes

I suspect there might be more cases like these, however these are the ones which have been found until now.

See #6871 (closed)