astUtils.canTokensBeAdjacent hardcoded espree.tokenize
See original GitHub issueTell 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).
Issue Analytics
- State:
- Created 4 years ago
- Comments:16 (14 by maintainers)
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.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 havetokenize
(and fall back toespree.tokenize
internally), and we could throw an error in 8.0.