feat!: Upgrade @typescript-eslint dependencies

[AndKiel]

https://github.com/typescript-eslint/typescript-eslint/releases/tag/v3.0.0

Changes summary

• recommended and recommended-requiring-type-checking configs now extend eslint-recommended (no need to extend eslint-recommended).

• ban-types rule now has very sensible defaults (which contain the stuff we already had).

• generic-type-naming and interface-name-prefix are now part of naming-convention. It was quite tricky to get it right so it wouldn't throw errors against canary.

• relevant disabled/enabled rules which were removed/added from/to recommended configs were removed or added where appropriate

Questions

1. Do we want to introduce more naming conventions apart from what we already have about interfaces and generics? The new rule is very flexible and has very nice options, for example this would be possible:

  {
      "selector": "variable",
      "types": ["boolean"],
      "format": ["PascalCase"],
      "prefix": ["is", "should", "has", "can", "did", "will"]
  }

2. Do we want to ban object?
   One of the entries in the new defaults for the ban-types is

object: {
  message: [
    'The `object` type is currently hard to use ([see this issue](https://github.com/microsoft/TypeScript/issues/21732)).',
    'Consider using `Record<string, unknown>` instead, as it allows you to more easily inspect and use the keys.',
  ].join('\n'),
},

which makes sense, although I expect it to possibly cause trouble. Some of our published packages use object type and it's hard to determine the impact of this rule on projects using them if it's introduced.

canary test run results

Upgrade preview: https://github.com/deepcrawl/canary/compare/style/eslint-config?expand=1
(no linting errors with the currently proposed configuration)

The following rules were determined to be faulty, resulting in false-positive errors, and had to be disabled:

• @typescript-eslint/no-unsafe-assignment
  e.g. const app = new cdk.App(); is considered "Unsafe assignment of an any value"

• @typescript-eslint/no-unsafe-call
  e.g. new CodebuildStack(app, "CanaryCodebuildStack") is considered "Unsafe construction of an any type value"

• @typescript-eslint/no-unsafe-member-access
  e.g. cdk.Tag.add(stack, "Team", "Ziggy") is considered "Unsafe member access .add on an any value"

• @typescript-eslint/no-unsafe-return
  e.g. localStorage.getItem return type is string | null but in the snippet below return is still considered any by the rule

  const apiUrl = localStorage.getItem("apiUrl");
  return apiUrl && apiUrl !== "" && apiUrl !== "null" ? apiUrl : "https://graph.deepcrawl.com/";

• @typescript-eslint/restrict-template-expressions
  e.g. works incorrectly with template literals in factories for tests or when literal is using generic type

Additionally, @typescript-eslint/explicit-module-boundary-types was disabled. The default recommended setting was warn but it seems to incorrectly report when types can be inferred.

[Nikamura]

i think for both questions answer is yes, boolean sounds good and banning object instead of record seems okay (but need to check how many erros we have)

[AndKiel]

i think for both questions answer is yes, boolean sounds good and banning object instead of record seems okay (but need to check how many erros we have)

Function is also banned by default but I skipped it when copying defaults. We have valid case for this type when writing decorators. We also use it in some places in which by Function we really mean constructor. Not sure how those would need to change to satisfy such a type ban.

@Nikamura, we could try banning object and enforcing boolean naming convention in a separate PR as not to make upgrade harder at this point.

[Nikamura]

yup, incremental changes

[AndKiel]

Follow-up tickets created for both questions:
https://deepcrawl.atlassian.net/browse/GRAPH-98
https://deepcrawl.atlassian.net/browse/GRAPH-99