tools: update eslint to v10

[JLHwung]

In this PR we bumped tools/eslint to v10 and the @babel/* to 8.0.0-rc.2, the first version shipped with ESLint v10 support.

The eslint rules are revised due to breaking changes in ESLint v10. To limit the size of this PR, I have also turned off one new recommended rules in v10: no-useless-assignment, as it introduced hundreds of errors across the codebase. We can investigate later if we want to enable this rule.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/single-executable

[JLHwung]

The ESLint v10 has modified the ranges of a Program to cover the leading comments.
https://eslint.org/docs/latest/use/migrate-to-10.0.0#-program-ast-node-range-spans-entire-source-text

As a result, the /* eslint-disable */ comment does not work if we still report error at the start of the program, since the comment will be after the start of the Program node. Here we report at the first statement.

c.f. eslint/eslint#20451

[JLHwung]

ESLint will automatically set sourceType of .cjs to commonjs, so we don't need specify the sourceType for cjs files.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.78%. Comparing base (199daab) to head (8c8490b).
⚠️ Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #61905      +/-   ##
==========================================
+ Coverage   89.75%   89.78%   +0.02%     
==========================================
  Files         674      674              
  Lines      204886   204955      +69     
  Branches    39376    39388      +12     
==========================================
+ Hits       183894   184014     +120     
+ Misses      13280    13216      -64     
- Partials     7712     7725      +13     

Files with missing lines	Coverage Δ
lib/internal/modules/cjs/loader.js	98.36% <100.00%> (-0.01%)	⬇️

... and 37 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71399/

[sheplu]

LGTM but do we want to wait for a stable release of babel?

[JLHwung]

do we want to wait for a stable release of babel?

I understand your concern, as a maintainer I am pretty confident about rc.2: features are frozen and the parser passed all test262 test cases for a long time. As the CI shows it also successfully parses all js files in this repo.

The remaining Babel 8 tasks towards a stable release are mostly typing improvements, as it is the first major Babel release with typing definitions. But we (the Node.js repo) don't use the typing part anyway so it is not very relevant.

I can open a new PR once Babel 8 reaches a stable release.