Use the built-in class fields and private methods rules in ESLint 8#14872
Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/52920/ |
|
The CI error is related: It seems like a package manager issue, I am investigating. |
|
OK. CI is failing because the sub module import |
9a02e1c to
ec9382c
Compare
|
@JLHwung Instead of forking I just created a small proxy package: https://github.com/nicolo-ribaudo/eslint-scope-5-internals |
|
The current E2E test is failing because ESLint v8 supports class properties / private methods, but We can detect ESLint v8 and make the following rules as no-op:
I don't think we should remove rules, in case in the future new syntaxes require extension again. |
295dfa3 to
0df1b61
Compare
| if (eslintVersion !== 8) { | ||
| if (isESLint7) { | ||
| if (process.env.IS_PUBLISH) { | ||
| console.warn("Skipping ESLint 7 test because using a release build."); |
There was a problem hiding this comment.
Now the published build will test against ESLint 8 only.
| const espreeAST = espree.parse(code, { | ||
| ...espreeOptions, | ||
| ecmaVersion: 2022, | ||
| ecmaVersion: "latest", |
There was a problem hiding this comment.
ESLint 8 also supports ES2023 so I put "latest" here.
13507a9 to
a730988
Compare
a730988 to
0bdf610
Compare
|
Rebased on latest main. |
|
I removed the label so that it doesn't go in the changelog (because this pr is for Babel 8) |
|
Well the bug fix commit 37ef28c will be shipped to Babel 7 anyway. |
@babel/semiconflicts with ESLint 8.0.0 when reporting class properties trailing commaseslint-scopeis bumped to 7.1.1 andeslint-visitor-keysto 3.3.0Bumped
eslint-scopeandeslint-visitor-keys. Because they drop Node.js 10 support, the update is behind theBABEL_8_BREAKINGflag.This PR also bumps
eslintdev dependencies to ESLint 8 and fixes compatibility issues of the following rules:semino-invalid-thisBecause ESLint 8 officially supported class properties / private methods. These rules become no-op when using with ESLint 8.
In this PR we also introduce a new test workflow
eslint7-testwhere we downgradeeslintto 7 and run theeslintrelated tests. The test is refactored so that we can test eslint parser/plugins against either ESLint 7 or ESLint 8, but not both. Compared to the current approach, the new approach@babel/eslint-parserwithESLINT_VERSION_FOR_BABEL = 7@babel/eslint-*with both ESLint 7 and ESLint 8Hopefully we can remove this workflow when we decide to drop ESLint 7 support in the future.
I wish we could match the Node.js release frequency, otherwise when our deps drop unmaintained Node.js versions support, we have to either 1) pin older versions because we can't drop EOL node versions in minors, or 2) fork the legacy dep and offer runtime switch like we did for
chokidar@2.