eslint with class property

How `babel-eslint` work with `eslint`, and the general workflow for linting and ast basics

On github: https://github.com/babel/babel-eslint/issues/487#issuecomment-564389834

Issue

If class property is used in class, eslint requires babel-eslint as parser (defaulted as espree) to parse the code before actual linting. For some reason, an error of eslint(no-undef) is always shown on the class property.

Firstly, I thought reason is @babel/plugin-proposal-class-properties is not provided for babel-eslint , while then I found actually babel-eslint always have class property as default plugin.

TL;DR

This should be solved by

{
    "eslint": ">=4.14.0",
    "babel-eslint": ">=8.1.0"
}

with fix from eslint/eslint PR#8755, and fix from babel/babel-eslint PR#542. Thanks to @mysticatea for the hard work.

--------

Explanation: This is a issue caused by the 'scope analyze' in eslint. In the older version (<4.14.0), eslint analyze the scope by its own without passing in the correct childVisitorKeys attribute.

// eslint.js
// gather scope data that may be needed by the rules
scopeManager = escope.analyze(ast, {
    ignoreEval: true,
    nodejsScope: ecmaFeatures.globalReturn,
    impliedStrict: ecmaFeatures.impliedStrict,
    ecmaVersion,
    sourceType: currentConfig.parserOptions.sourceType || "script",
    fallback: Traverser.getKeys
});

https://github.com/eslint/eslint/blob/421aab44a9c167c82210bed52f68cf990b7edbea/lib/eslint.js#L892

A correct scope after parser.parse() requires corresponding childVisitorKeys defined by different parser, as PR#8755 explains

After those two PRs, babel-eslint will generate the scopeManager with its own modification. eslint will consume the scopeManager (const scopeManager = parseResult.scopeManager;), and apply rules over it.

Take away:

1. It costs time to locate the root cause for this kind of issue if you are not familiar with the massive project like eslint (or ast concept), not to mention it normally comes with several more issues together.

2. If you really want to do the research, start from the rules folder and analyze specific rule to get two cents about what goes wrong, in this case, it's the scope. It would be much easier then to narrow down your research in scope-related logic in parse().

3. The easy way to 'just make things work' maybe is always upgrade version.

How eslint(v4) compiles code

eslint.js(entry) -> CLIEngine(options) -> processWithText(text, options) -> linter.verify(text, options)

Inside verify(), sourceCode = parse(text, parser, parseOptions) -> analyze sourceCode.ast

• load and analyze an ast for a 200 line file is not too practical

How linter analyse ast

• sharedTraversalContext contains scope info

• scope analyzer is important for rules to check scope and variables