feat: Support ES2023 and hashbangs #556
Conversation
There was a problem hiding this comment.
could you also update the readme: https://github.com/eslint/espree#what-ecmascript-features-do-you-support?
|
Hashbangs will have |
|
I’m ambivalent about the token name. On one hand, ESLint itself handles hashbangs already, and we can’t remove that functionality for backwards compatibility, so it really doesn’t matter what the token is. The question is more what would consumers other than ESLint expect this token to be? |
By default, the `ecmaVersion` test runner was not asking the parser for comments. Now, when the source filename contains `comment`, it sets `comment: true` and includes comments in the expected result. This extends the precedent set by filenames containing strings like `"non-strict"`, `"edge-cases"`, `"modules"`, and a few others, all of which put the test runner in slightly different modes.
Reviewers asked for the hashbang comment to have a type distinct from `"Line"` [1]. ESLint already handles hashbangs internally, and removing its custom handling would break backwards compatibility. The name is therefore up to whatever non-ESLint users of Espree would expect. [2] The hashbang grammar proposal already addressed this choice directly [3], so this commit defines the type as `"Hashbang"` to match the proposal. [1]: #556 (comment) [2]: #556 (comment) [3]: https://github.com/tc39/proposal-hashbang#why-hashbang-instead-of-shebang
|
The proposal includes a section on "why hashbang instead of shebang". Since ESLint's precedent of calling it |
Acorn enabled the hashbang grammar when
ecmaVersionis 2023 in acornjs/acorn@b2ecf7a, which was released in v8.8.0.This change adds 14/2023 as valid
ecmaVersions(which automatically incrementslatest).When Acorn's constructor encounters
#!at the beginning of input, it transitively calls ouronComment()handler. I therefore needed to move Espree'sstateto before thesuper()call and make it usable beforethisis accessible.