feat: add eslint 10 support

[bjnewman]

Hi! This adds ESLint 10 support, closing #1075.

Tested locally against ESLint 3–10 — all tests pass across every version.

What changed

RuleTester wrapper — The previous wrapper overrode RuleTester.prototype.run, which breaks in ESLint 10 due to new stack-frame introspection in getInvocationLocation(). Rewrote it to use only the documented RuleTester.describe and RuleTester.it hooks instead. The new approach uses a simple module-level variable with stack-based save/restore instead of storing state as properties on function objects, so mock-property is no longer needed and has been removed from devDependencies.

TestCaseError#type removal — ESLint 10 dropped the type property from test case errors. Rather than touching all 39 rule test files, the parserOptionsMapper now conditionally strips type from error objects for ESLint 10+ (using the existing object.fromentries and object.entries dependencies).

Stray errors on valid test cases — ESLint 10 validates that valid test cases don't include errors. Five test files had valid cases with an accidental errors property that ESLint 9 silently ignored. Removed the stray property from each.

CI matrix — Added eslint: 10 with Node version exclusions matching ESLint 10's engine requirement (^20.19.0 || ^22.13.0 || >=24).

Compatibility smoke test — New eslint-compat-test.js exercises the RuleTester/tape integration end-to-end with sequential runs to catch state management regressions in the wrapper.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​eslint@​10.0.0

View full report

[ljharb]

Why are errors being removed from the test cases?

[bjnewman]

To my best understanding, these errors were on valid test cases — they were never checked by ESLint's RuleTester and had no effect on test behavior.

ESLint 10 appears to have added assertValidTestCase validation that rejects valid test cases with an errors property (since valid cases should not produce errors). With ESLint ≤9 these seem to have been silently ignored; with ESLint 10 they cause TypeError: Cannot read properties of undefined (reading 'slice').

Specifically:

• aria-unsupported-elements-test.js — <fake aria-hidden /> is in the valid array but had errors
• autocomplete-valid-test.js — 4 cases under "PASSED autocomplete-appropriate" are in the valid array but had errors: inappropriateAutocomplete (making the variable unused, so it was also removed)
• html-has-lang-test.js — <HTMLTop lang="en" /> is in the valid array but had errors
• no-noninteractive-tabindex-test.js — 2 role-expression cases in the valid array had errors
• no-static-element-interactions-test.js — 2 role-expression cases in the valid array had errors

Apologies for not calling this out more clearly in the description — it's mentioned briefly under "Stray errors on valid test cases" but should have included these specifics upfront.

Happy to be corrected if I've misread any of these — please let me know!

[StephanTLavavej]

Do you want to disclose your use of generative AI while creating this PR and its description?

[bjnewman]

@StephanTLavavej I'm happy to. I became interested in LLM-assisted open source contribution after modernizing several legacy applications at my day job. Happy to discuss further outside this PR if you're curious about the workflow.

[ljharb]

Unfortunately LLM output can't be copyrighted, and thus can't ever be a valid open source contribution. Please do not ever use LLMs for generating open source work. If you've done so here, please remove it and rewrite it by hand.

As for the error removal - a separate commit that just removes the errors on valid test cases would be helpful.

[bjnewman]

Closing this PR — I respect maintainers' right to set contribution policies.

As someone with a J.D., I'll briefly note that the legal claim here is oversimplified. U.S. copyright law distinguishes between purely AI-generated works (not copyrightable) and human-authored works created with AI assistance (copyrightable per the Copyright Office's March 2023 guidance). These are different categories. But this isn't the venue for that debate — happy to leave it there.

[ljharb]

To be clear, I'm not objecting to using LLMs to suggest changes and debug problems, or even for automating application of human-produced changes - just for letting it write the code for you. The line between "AI assistance" and "purely AI-generated" is untested in court (to my knowledge) and as such seems like a subjective determination of the copyright office and/or a judge, so zero-budget open source projects don't likely have the wherewithal to take on that risk.

[bjnewman]

Counteroffer: you teach me how to write code better and I will explain why I think you are wrong on the legal analysis and risks.