Changes to the eslint-recommended ruleset for 3.0.0

[bradzacher]

Reviewing rules, we can add some new rules to this set in the next major.

• constructor-super ([constructor-super] Duplicates TypeScript's TS2335 and TS2377 errors #1248)
  • repl
  • 'super' can only be referenced in a derived class. (2335)
  • Constructors for derived classes must contain a 'super' call. (2377)
• no-func-assign ([no-func-assign] Duplicates TypeScript's TS2539 error #983)
  • repl
  • Cannot assign to 'foo' because it is not a variable. (2539)
• no-import-assign
  • repl
  • Cannot assign to 'mod' because it is not a variable. (2539)
  • Cannot assign to 'SyntaxKind' because it is not a variable. (2539)
  • Cannot assign to 'SyntaxKind' because it is a read-only property. (2540)
• no-setter-return
  • repl
  • Setters cannot return a value. (2408)
• no-obj-calls ([no-obj-calls] Duplicates TypeScript's TS2349 error #999 / feat(eslint-plugin): eslint-recommended: disable no-obj-calls #1000)
  • repl
  • Type 'Math' has no call signatures. (2349)
• no-unsafe-negation ([no-unsafe-negation] Duplicates TypeScript's TS2358, TS2360, and TS2365 errors (?) #1146)
  • repl
  • Operator '<' cannot be applied to types 'boolean' and 'number'. (2365)
  • The left-hand side of an 'in' expression must be of type 'any', 'string', 'number', or 'symbol'. (2360)
  • The left-hand side of an 'instanceof' expression must be of type 'any', an object type or a type parameter. (2358)

[wtgtybhertgeghgtwtg]

Will prefer-optional-chain and prefer-nullish-coalescing make the cut?

[bradzacher]

@wtgtybhertgeghgtwtg - the eslint-recommended set is different from the recommended set.

eslint-recommended is intended to be used with eslint's base recommended set, and it disables all rules that are known to be covered by the typescript typechecker.

---

It's highly likely that prefer-optional-chain and prefer-nullish-coalescing will make the cut into our recommended set though.

[glen-84]

1. I hadn't mentioned no-setter-return because I thought that this set only disabled recommended rules (and no-setter-return is not marked as recommended).
2. I'm not actually using this set, but I do wonder why this is considered a breaking change, since it is only used by TypeScript users, who will already be seeing the TypeScript errors. These users would either have broken code (because of the TS errors), or they would have neither TS errors nor the related ESLint errors.

[bradzacher]

I do wonder why this is considered a breaking change

Some users do rely on linting to catch problems when using babel as their transpiler.
I've seen setups where people run eslint and babel via webpack, but not the typescript checker.
So adding rules to this would reduce their build safety, so it's best to make it breaking, just in case.

[aggmoulik]

Hy, @bradzacher is there anything I can work on?

[bradzacher]

@moulikcipherX there's no shortage of issues to look at.
There are plenty tagged with "good first issue" which should be doable.
Pretty much any issue without the "has PR" is fair game.

https://github.com/typescript-eslint/typescript-eslint/blob/master/CONTRIBUTING.md#pull-requests