ESLint v10 support

[rasmi]

Summary

Add ESLint v10 support while maintaining backward compatibility with ESLint v2–v9. The v10 compat changes in shipped code use feature detection (e.g. checking if context.languageOptions exists) rather than version checks.

Closes:

• Compatibility with ESLint 10 #3227
• Following the ESLint 9 support, import/no-unused-modules only works in flat config if an .eslintrc file exists as well #3079

Split out into separate PRs (independent / pre-existing issues revealed during v10 update; this branch rebases onto them and becomes v10-only):

• Resolve export * as ns re-exports under modern parsers #3250: for issues [export] incorrect report on export * as #2002, export * as ns false positive on import/named rule #1883, [import/export] False "Multiple exports of name" error when two "export * as ..." contain same name.  #1834, import/named and import/namespace errors after upgrading Babel #1845, False "Multiple exports of name" error when two "export * as ..." contain same name [import/export]  #2289
• Remove stray errors from valid tests. #3251
• Replace eslint-plugin-json with a fixture processor #3252: (maybe)

What changed

Removed API replacements

ESLint v10 removed several deprecated context properties and SourceCode methods. Each call site now feature-detects the new API and falls back to the old one:

• context.parserOptions → context.languageOptions.parserOptions (affects sourceType.js, childContext.js, typescript.js, scc.js, parse.js)
• context.parserPath → context.languageOptions used for cache hashing instead (scc.js)
• context.getPhysicalFilename() → context.physicalFilename property (contextCompat.js)
• context.getScope() → already had a compat wrapper, but one call site in declaredScope.js bypassed it — now fixed
• sourceCode.getTokenOrCommentAfter/Before() → sourceCode.getTokenAfter/Before(node, { includeComments: true }) (order.js)

no-unused-modules file enumeration fallback

ESLint v10 removed FileEnumerator and the internal glob-utils module. The existing cascade (FileEnumerator → legacy glob-utils) now has a third tier: a Node.js fs + minimatch fallback that walks directories and matches globs.

• Only reached when both prior methods throw MODULE_NOT_FOUND or ERR_PACKAGE_PATH_NOT_EXPORTED
• Uses minimatch and is-glob (existing direct dependencies)
• On v10, this resolves #3079 (flat config requiring a dummy .eslintrc) since FileEnumerator is no longer used. The issue remains on v9.

Test infrastructure (test files only)

On v10, the unmaintained babel-eslint (Babel 6) is replaced with @babel/eslint-parser v8 for test coverage. This restores ~475 babel-related tests that would otherwise be skipped on v10.

• FlatCompatRuleTester extended to auto-inject @babel/eslint-parser config (requireConfigFile: false, babelrc: false, syntax plugins) and handle v10 RuleTester strictness
• 5 no-duplicates tests skipped: duplicate import identifiers correctly rejected by @babel/eslint-parser
• TypeScript syntax tests gated for @typescript-eslint/parser v8 (import type Default, { Named } removed in TS 5.0)
• Angular template parser upgraded to v21 on v10 (v13 does not support ESLint 10; angular-eslint#2903)
• [import/no-unused-modules] - "No files matching the pattern" error #1645 runs on v10 via a new fixture in Replace eslint-plugin-json with a fixture processor #3252

Dependency changes

Package	Change	Why
eslint	|| ^10 added to peerDeps and devDeps	v10 support

v10-specific parser deps are installed via dep-time-travel.sh (not in devDeps) to avoid peer dep conflicts with typescript@4.5.5 during npm install:

• @typescript-eslint/parser@8 — on all ESLint 10 Node versions
  -@angular-eslint/template-parser@21 — on all ESLint 10 Node versions (v13 does not support ESLint 10)
• @babel/eslint-parser@8 + @babel/core@8 (ESM, RC) — on Node >= 20
• No babel parser on Node 18/19/21 (v8 is ESM-only, engines ^20.19.0 || >=22.12.0; v7 will not get ESLint 10 support). Babel tests are skipped; all other tests run.

CI changes

• eslint-8+.yml: added ESLint 10 to the matrix, excluded Node < 18
• dep-time-travel.sh: installs v10-specific parser deps (@typescript-eslint/parser@8 and @angular-eslint/template-parser@21 on all nodes, @babel/eslint-parser@8 on Node >= 20 only)
• See also Fix resolve install in old npm version on CI. #3237 to fix tests failing in main.

[codecov]

Codecov Report

❌ Patch coverage is 26.66667% with 88 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.95%. Comparing base (b3cf7e1) to head (99d5a50).
⚠️ Report is 9 commits behind head on main.

Files with missing lines	Patch %	Lines
src/core/listFilesToProcess.js	10.41%	43 Missing ⚠️
src/core/listFilesWithNodeFs.js	31.91%	32 Missing ⚠️
src/core/getTokenOrComment.js	0.00%	8 Missing ⚠️
src/exportMap/typescript.js	28.57%	5 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (b3cf7e1) and HEAD (99d5a50). Click for more details.

HEAD has 19 uploads less than BASE

Flag	BASE (b3cf7e1)	HEAD (99d5a50)
	40	21

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #3230       +/-   ##
===========================================
- Coverage   95.82%   80.95%   -14.88%     
===========================================
  Files          83       97       +14     
  Lines        3741     4438      +697     
  Branches     1355     1535      +180     
===========================================
+ Hits         3585     3593        +8     
- Misses        156      845      +689     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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.

[StephanTLavavej]

@rasmi Do you want to disclose your usage of LLMs to generate this PR description and/or PR, which @ljharb objected to in another repo jsx-eslint/eslint-plugin-jsx-a11y#1077 ?

[rasmi]

Was not aware, thanks @StephanTLavavej! It is a bit disappointing, as I spent a few hours of my day working on this, even with LLM tools. I will close this PR regardless out of respect for the maintainer (I just want to make sure the tests pass for my own edification).

[dirkluijk]

Just curious (and with all respect), what is the real issue of LLM-generated code? What matters is the code, right?

If the PR is too big, or too hard to review, we could just improve that?

[ljharb]

@StephanTLavavej please do not take it upon yourself to act as if you're a maintainer. Each project can have different policies regardless of who's maintaining them. Please do not attempt to police projects you aren't even a significant contributor to.

@rasmi if you're using an LLM to automate applying changes you're writing, I'm fine with that - however if you're just prompting one to "add eslint v10 support", i have my own LLM subscription for that kind of thing :-)

@dirkluijk no, "what matters" has never been, and never will be, just "the code". Any code contribution represents a legal assignment of rights, as well as an eternal maintenance burden on that code, and as such, the human contributor is an important factor.

[rasmi]

@ljharb -- point well-taken! I did go through a more rigorous process here -- it really did take me hours of focused work, thinking about implementation approaches, iterating, fixing tests, etc. It is not my intention to submit slop, I wanted to submit a PR that I hoped would meet the standard of the library, at least as a first pass. I lack decision-making insight/context on things like "Is it okay to just use glob, if not let's do a custom file search" and "exactly how should node vs. eslint-parser vs. core library version compatibility be handled" -- but this is what the review process is for!

I also understand that big changes like this may be simpler for the maintainer to just take on directly, as you have all the proper context and expertise on all the nuances of the library and ecosystem, to say the least. Apologies again, I didn't mean to burden you at all, I know it is hard to maintain core libraries like this. Please do with this what you wish!

[A-Loot]

What is the current status of this PR?

[rasmi]

Hi @ljharb -- let me know if you have any feedback / next steps on this that I can address. Sorry to ping you, but there is quite a crowd on this PR and #3227. If the issue is codecoverage, I can add new test coverage. I think my main concern was whether some of the design decisions are appropriate for the project. (just rebasing onto main & force-pushing now)

[rasmi]

#3237 should fix the tests currently failing in main.

[captaindonald]

@ljharb I opened rasmi/eslint-plugin-import#1 against @rasmi's eslint-update to clear the failing codecov/patch + codevov/project here - no targets, thresholds, or ignores changed, just covers the two new v10 spots that were uncovered: the getTokenOrComment feature-detect arms in order, and the ERR_PACKAGE_PATH_NOT_EXPORTED fallback in listFilesToProcess. Merge it into the branch, or pull the commits straight into this PR - whichever is easier.

[captaindonald]

Ok, this one should clear that -0.04%.

rasmi#2

[captaindonald]

Codecov being codecov again. Failed uploads.

[ljharb]

Codecov isn't a blocker, don't worry.

[manzoorwanijk]

Thank you @ljharb

[TheGiraffe3]

And thanks @captaindonald!

[ThomasAFink]

Thank you for this!