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

looks like its working, we have to change logic inno-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 thatNodeListOf is not defined.

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

Amazing!

Hm. I have thought that we should use twoScopeManager 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.

(soclass A {} interface A {} is redeclaration.)

Therefore, my thought is aScopeManager manages only variables and variable references for core rules, and anotherScopeManager manages only types and type references inparserServices. (but I'm not sure ifScopeManager for types is needed because we can useTypeChecker of TS compiler API.)

If a singleScopeManager manages both, I think that scopes will havetypes andtypeReferences, and the resolving logic connectsvariables ⇔references andtypes ⇔typeReferences.

Though, we needTypeChecker 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 withTypeChecker API rather than modifying core rules.

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 makingno-shadow-types for this

thanks@mysticatea for this idea 👍

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