feat(parser): Draft of scope analysis with types

[armano2]

This is early stage of updated scope-analysis with types included into scope, there is still a lot to do.
Goal of this PR is to solve #18, #19, #21, #60, #207 #122, #249

• update variable resolution to use 2 "sub scopes", type and var
• add missing scopes for type, interface
• add test scenarios test(parser): change tests in parser to scope analysis #234
• visiting props of TSDeclareFunction fix(parser): fix visiting props of TSDeclareFunction #244
• add regression tests for eslint rules test(eslint-plugin): add test cases for eslint rules #240
• visiting decorators in parameters fix(parser): fix crash when visiting decorators in parameters #237
• fix no-undef (we should ignore types)
• no-use-before-define (we have to add support for types)

[armano2]

i decided to split this PR to few smaller one (fixes for non types), and after they are going to be merged i will continue working on types

#244 #240 #237 #234

[armano2]

looks like its working, we have to change logic in no-undef from eslint scope i have no access to global types defined by user or typescript, and there are false positives in this rule because of that:

const links = document.querySelectorAll( selector ) as NodeListOf<HTMLElement>

even if you specify globals for browser and es6 it will report that NodeListOf is not defined.

@typescript-eslint/core-team @mysticatea i will appreciate some feedback (and maybe some suggestions for tests)

[mysticatea]

Amazing!

Hm. I have thought that we should use two ScopeManager instance for variables and types because variables and types are different concepts.

In TypeScript, a declaration creates entities in at least one of three groups: namespace, type, or value. Namespace-creating declarations create a namespace, which contains names that are accessed using a dotted notation. Type-creating declarations do just that: they create a type that is visible with the declared shape and bound to the given name. Lastly, value-creating declarations create values that are visible in the output JavaScript.
https://www.typescriptlang.org/docs/handbook/declaration-merging.html

Varaible references must not resolve to types and type references must not resolve to variables. Some entities such as classes and enums belong to both the variable scope and the type scope.

(so class A {} interface A {} is redeclaration.)

Therefore, my thought is a ScopeManager manages only variables and variable references for core rules, and another ScopeManager manages only types and type references in parserServices. (but I'm not sure if ScopeManager for types is needed because we can use TypeChecker of TS compiler API.)

If a single ScopeManager manages both, I think that scopes will have types and typeReferences, and the resolving logic connects variables ⇔ references and types ⇔ typeReferences.

Though, we need TypeChecker to know imported bindings belong to which area. :(

---

About variable rules in the plugin, I believe that we should deprecate those to avoid doing duplication. But If we decide to maintain those, I think that we should implement those with TypeChecker API rather than modifying core rules.

[armano2]

hmm, this is good idea to split it, but i think it should be one ScopeManager with separated refferences and variables that we can share only some declarations between between types and variables

i will change this that scope has 2 types of references and core rules are going to work only for variables

i'm going to have to fix only no-unused-vars to check for types and other rules will have to be re-implemented for types.

---

no-unused-variables and other rules/checks witch can be done by tsc, can be migrated but only after we solve performance issue with creating programs...

---

even if we decide to leverage tsc as replacement for some of rules we still need scope for types to implement rules not supported by it.

no-shadow is good example, typescript is not warning user about this and this is great rule to catch some potential issues

class foo<T> {
  test<T>() {}
}

with this new implementation (splitting references) we should consider making no-shadow-types for this

thanks @mysticatea for this idea 👍

[JamesHenry]

Please can we reopen this using the new WIP PR feature on GitHub?