astUtils.canTokensBeAdjacent hardcoded espree.tokenize

Tell us about your environment

• ESLint Version: 6.4.0
• Node Version: 10.16.0
• npm Version: 6.9.0

What parser (default, Babel-ESLint, etc.) are you using?

Please show your full configuration:

Configuration

module.exports = {
  parserOptions: {
    ecmaVersion: 2020,
  }
};

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 no-implicit-coercion:error */

let x ="" + 1n;

eslint index.js

What did you expect to happen?

let x =String(1n);

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

SyntaxError: Identifier directly after number at Espree.raise ... canTokensBeAdjacent.

Problem

astUtils.canTokensBeAdjacent can accept a string value, which is useful when fixer adds some new code. But, it’s using hardcoded espree.tokenize with ecmaVersion: 2015.

The same problem occurs with the following code when babel-eslint is used:

/* eslint no-implicit-coercion:error */

class Foo {
  #a = 0;
  bar() {
    let x ="" + this.#a;
  }
}

Are you willing to submit a pull request to fix this bug?

Yes, but I’m not sure what would be the best approach. Whether to use the configured parser and configured options, or to somehow avoid this feature e.g., pass a token-like object instead of a string (that would require a change in 4-5 rules though).

[not-an-aardvark]

We could use a try-catch and return a safe default value if espree fails.

astUtils.canTokensBeAdjacent is a function that makes a best-effort attempt to avoid unnecessary spacing in autofixes. It’s an extremely minor feature, and it doesn’t need to be completely perfect as long as it does fallbacks appropriately (worst-case scenario, some autofixed text will have an unnecessary space in it). That’s why I think it’s silly to require parsers to supply an entirely new API for this. We should stop it from crashing, but we don’t need to do the tokenization perfectly.

[platinumazure]

I agree that we should eventually require tokenize, but I don’t think we can do that for 7.0. I think we should check the parser object and emit a warning in 7.0 if it doesn’t have tokenize (and fall back to espree.tokenize internally), and we could throw an error in 8.0.