Exceptions when traversing using sibling, adjacent and nth-child selectors and non-standard AST nodes

Tell us about your environment

• ESLint Version: v7.7.0
• Node Version: v12.14.1
• npm Version: v6.13.4

What parser (default, @babel/eslint-parser, @typescript-eslint/parser, etc.) are you using?

@typescript-eslint/parser

Please show your full configuration:

Configuration

module.exports = {
  "parser": "@typescript-eslint/parser",
  "plugins": [ "eslint-plugin-test" ],
  "rules": { "test/test": "error" }
};

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

eslint-plugin-test source:

exports.rules = {
    test: {
        create(context) {
            return {
                "Program ~ *": node => {
                    context.report({
                        message: "test",
                        node
                    })

                    // this code doesn't get a chance to get called :(
                }
            }
        }
    }
}

lint file source:

const foo: string = "bar"

eslint ./test.ts

What actually happened? Please include the actual, raw output from ESLint.

Oops! Something went wrong! :(

ESLint: 7.7.0

TypeError: Cannot read property 'length' of undefined
Occurred while linting /home/samual/test/index.ts:1
    at u (/home/samual/test/node_modules/esquery/dist/esquery.min.js:1:31904)
    at Function.l [as matches] (/home/samual/test/node_modules/esquery/dist/esquery.min.js:1:30807)
    at NodeEventGenerator.applySelector (/home/samual/test/node_modules/eslint/lib/linter/node-event-generator.js:253:21)
    at NodeEventGenerator.applySelectors (/home/samual/test/node_modules/eslint/lib/linter/node-event-generator.js:281:22)
    at NodeEventGenerator.enterNode (/home/samual/test/node_modules/eslint/lib/linter/node-event-generator.js:297:14)
    at CodePathAnalyzer.enterNode (/home/samual/test/node_modules/eslint/lib/linter/code-path-analysis/code-path-analyzer.js:673:23)
    at /home/samual/test/node_modules/eslint/lib/linter/linter.js:949:32
    at Array.forEach (<anonymous>)
    at runRules (/home/samual/test/node_modules/eslint/lib/linter/linter.js:944:15)
    at Linter._verifyWithoutProcessors (/home/samual/test/node_modules/eslint/lib/linter/linter.js:1170:31)

Context

Original issue: https://github.com/typescript-eslint/typescript-eslint/issues/2439

Investigation so far:

Our parser (@typescript-eslint/parser) returns an extended list of visitor-keys (as specified by the ESLint docs) right here

However esquery uses its own (hard coded) visitor keys for 3 selectors:

• sibling ~: https://github.com/estools/esquery/blob/e27e73d8cde63a2eb1aba3424510ce1b714d207e/esquery.js#L239
• adjacent + https://github.com/estools/esquery/blob/e27e73d8cde63a2eb1aba3424510ce1b714d207e/esquery.js#L275
• and nth-child :nth-child(n) https://github.com/estools/esquery/blob/e27e73d8cde63a2eb1aba3424510ce1b714d207e/esquery.js#L309

So I think that this is this something we’ll have to PR into the underlying esquery library?

[brettz9]

esquery has just published a new release with the support for custom visitor keys, so I think this should no longer be blocking.

[mdjermanovic]

I think we should treat this as a bug, since our selectors documentation lists those selectors, so it’s reasonable to expect that they can work with custom parsers.

Also, they’ll crash even with the default parser on any JSX code, as in this demo.

It’s true that this needs to be supported in esquery first, so we could pass visitors keys.

Relevant PR: https://github.com/estools/esquery/pull/112

An alternative is to remove those selectors from the documentation. If this doesn’t get fixed, it seems best not to use them at all.