Support for typed TSLint rules

[JoshuaKGoldberg]

TSLint has some rules that use typed checked rules are able to tap into the full type intelligence from TypeScript, so they can leverage the full type system in their linting.

(some higher value rules that aren't really possible without type information here...)

• no-unnecessary-type-assertion/
• await-promise/
• no-floating-promises
• no-for-in-array
• no-unbound-method
• no-unsafe-any
• restrict-plus-operands
• strict-boolean-expressions
• strict-type-predicates
• prefer-readonly/
• unnecessary-bind

Although versions of some typed rules are available in ESLint & its plugins, they fall apart when interacting with objects whose types can't be inferred statically using just the file: for example, if linting code that imports objects from another file/module.

The recent TypeScript Jan-Jun 2019 Roadmap reminded me of a tweeted suggestion to file this here. Is this the right place? Would ESLint core need structural improvements to support full-program type checking?

[armano2]

@JoshuaKGoldberg we started working on rules like this :)
#250 #269 but we are kind block by parser eslint/typescript-eslint-parser#568 witch is blocked by eslint/typescript-eslint-parser#592

[JoshuaKGoldberg]

Ooh! Looking through that PR:

context.parserServices.program.getTypeChecker();

TIL that's available, great! Do you have docs on this? I can't find any in this repo.

[j-f1]

There’s a PR open in typescript-eslint-parser to add a way for rules to get type information: eslint/typescript-eslint-parser#568. Once that’s merged, we’d appreciate help creating rules that use this type info!

[JoshuaKGoldberg]

I'll close this issue in favor of making two dedicated ones: docs and rule parity. Thanks! 😍

[j-f1]

We don’t have docs here as far as I know, but getTypeChecker() returns an instance of TS’s TypeChecker class provided directly by TS.

[j-f1]

I’m wondering if we should move all the TS+ESLint stuff to an @eslint-typescript org so changes can be released more quickly.