I wanted to merge all of the scope analysis rule issues together into a single meta-issue. So I could centrally provide some context on what the problem is, and what needs to be done.

The Problem

The no-unused-vars rule, as with many other rules in ESLint [1][2] relies upon scope analysis.

For context; an ESLint parser may additionally provide a ScopeManager alongside the AST it produces. A ScopeManager is a utility class which can be used to interrogate the variables available in a certain scope.

ESLint rules can then use this ScopeManager to gather information about the variables that are included in the current scope - i.e. what variables are defined.

Other parsers (such as babel-eslint) provide scope analysis, but most other parsers have a smaller scope of extensions to support, so they can just build on top of the existing scope manager, or they get around it via "extension" rules to either mark things as used, or to ignore things from rules entirely.

In TypeScript's case, in order for us to properly describe the scope and usage across TS's dual-scope system, it would require a large rewrite of the scope analyser (eg #1533).

This is never something we invested much time into for a number of reasons like:

• most of the rules that use the scope manager are either infrequently used, or have analogous checks/options in the TypeScript itself,
• we wanted to be careful that we wouldn't implement something that would get outdated by changes to the underlying TS language,
• we explored other options that would not require scope analysis:
  • manually marking nodes via context.markVariableAsUsed.
    • This got us a decent chunk of the way, but it's not a great way to handle all of the cases and scope boundaries.
  • no-unused-vars-experimental.
    • This was a great idea in theory, but the getSemanticDiagnostics API is too slow for the rule to be usable on large codebases (~30ms per file) ([no-unused-vars-experimental] rule is slow #1335)
• the inner workings of eslint-scope are relatively poorly documented, so implementing TS scope into it was always a large task.

The Solution

It's become very clear that we need to bite the bullet and just do this work.
We're currently building out a full scope manager (#1939), but it is not a small task, so please be patient.