Support ESLint version 10 (fixes #92)

[Standard8]

Generally upgrade the dependencies. The only change for ESLint 10 is to drop the type option for errors in RuleTester, as the option is no longer supported (fixes #92)

[Standard8]

@microsoft-github-policy-service agree company="Mozilla Corporation"

[Standard8]

The test error here appears to be the same issue as on main.

[romanresh]

We're also waiting for merge of this PR.

[Standard8]

@mkacmar Is this still supported? Would we be able to get this into a new release?

[mozfreddyb]

@A-Katopodis Can you help us out here?

[Standard8]

@mkacmar @A-Katopodis Is there anything we can do to help this along, or should we consider this abandoned & obsolete it now?

It'd be useful to get a clear picture on the support for this for an ongoing basis.

[BearCooder]

Hey @plade I saw that you rewieved the other PR recently and approved. Could you help us out here with a review to land eslint 10 support soon?
This is getting increasingly urgent as ESLint 9.x goes EOL on August 6th,

Thanks

[plade]

Deleted this comment and replaced with inline review comment.

[plade]

ESLint 10 compatibility review

[plade]

ESLint 10 support is incomplete with the current dependency graph. Please address these items before advertising ^10 here:

1. Upgrade @typescript-eslint/eslint-plugin and @typescript-eslint/parser together to a current v8 release whose peer range includes ESLint 10 (for example, ^8.65.0). Since config/typescript.js loads these packages from the exported configuration, move them from devDependencies to dependencies unless TypeScript support is redesigned as an optional peer feature.

2. Remove eslint-plugin-react@7.37.5; its peer range ends at ESLint 9, so a clean ESLint 10 consumer install can fail with ERESOLVE. The React preset uses only no-danger, jsx-no-target-blank, and iframe-missing-sandbox. For dual ESLint 9/10 support, SDL-owned equivalents avoid retaining an incompatible dependency. @eslint-react/eslint-plugin has equivalents for the latter two, but its current ESLint/Node minimums would drop ESLint 9 and Node 20 support.

3. Pass the parser object in the flat config instead of the package-name string:

const parser = require("@typescript-eslint/parser");

languageOptions: {
  parser,
  parserOptions: {
    ecmaVersion: 6,
    sourceType: "module"
  }
}

4. Add CI coverage for ESLint 9 and 10. ESLint 10 jobs must use Node >=20.19. Include a clean consumer installation and execute configs.recommended against JS, JSX, TS, and TSX fixtures.

5. Remove continue-on-error: true from the E2E ESLint step so plugin-load failures and rule crashes fail the workflow.

After these changes, "eslint": "^9.0.0 || ^10.0.0" is appropriate. Run ESLint's migration codemod as a starting point:

npx codemod @eslint/v9-to-v10

Sources:

• ESLint 10 migration guide
• typescript-eslint supported dependency versions
• Migration from eslint-plugin-react

[Standard8]

I'd be willing to update this IF I can get commitment that it is actually going to get accepted and released. 6 months of pinging people and not getting a response is not acceptable. I'm strongly considering just forking the bits we need so that we don't have this hassle every time TypeScript updates.

1. Upgrade `@typescript-eslint/eslint-plugin` and `@typescript-eslint/parser` together to a current v8 release whose peer range includes ESLint 10 (for example, `^8.65.0`). Since `config/typescript.js` loads these packages from the exported configuration, move them from `devDependencies` to `dependencies` unless TypeScript support is redesigned as an optional peer feature.

I could move these to be an optional peer dependency.

2. Remove `eslint-plugin-react@7.37.5`; its peer range ends at ESLint 9, so a clean ESLint 10 consumer install can fail with `ERESOLVE`. The React preset uses only `no-danger`, `jsx-no-target-blank`, and `iframe-missing-sandbox`. For dual ESLint 9/10 support, SDL-owned equivalents avoid retaining an incompatible dependency. `@eslint-react/eslint-plugin` has equivalents for the latter two, but its current ESLint/Node minimums would drop ESLint 9 and Node 20 support.

Maybe also an optional peer dependency, which would then mean that the React option wouldn't work until eslint-plugin-react upgrades, but there's not much we can do about that.

4. Add CI coverage for ESLint 9 and 10. ESLint 10 jobs must use Node >=20.19. Include a clean consumer installation and execute `configs.recommended` against JS, JSX, TS, and TSX fixtures.

As far as I can tell, we had no support for this previously (e.g. 8 -> 9), and there's no current infrastructure. I'm not going to work on this. ESLint 9 is stable and it is less likely to be broken since it has basically the same API as ESLint 10.

5. Remove `continue-on-error: true` from the E2E ESLint step so plugin-load failures and rule crashes fail the workflow.

This seems unrelated to making things work with ESLint 10.

After these changes, "eslint": "^9.0.0 || ^10.0.0" is appropriate. Run ESLint's migration codemod as a starting point:

Why? The major parts were already tested as being compatible.