feat: Add getPossibleTypesForSelectorClass to Language interface by Kuldeep2822k · Pull Request #148 · eslint/rfcs

Kuldeep2822k · 2026-05-23T06:31:42Z

Summary

Add an optional getPossibleTypesForSelectorClass(className) method to the Language interface that allows languages to declare which AST node types could match a given pseudo-class selector (e.g., :function). This removes hardcoded JavaScript-specific logic from the core selector analysis in lib/linter/esquery.js and enables any language plugin to provide the same optimization.

Related Issues

Discussion #20856 — Original discussion: "Should we move JS-specific ESQuery analysis logic into the Language interface?"
RFC #99 — ESLint Language Plugins (introduced the Language interface)
esquery External class resolve PR — The mechanism that enabled matchesSelectorClass()

eslint-github-bot · 2026-05-23T06:31:50Z

Hi @Kuldeep2822k!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the pull request title to match this format, as we use it to generate changelogs and automate releases.

The commit message tag wasn't recognized. Did you mean "docs", "fix", or "feat"?
There should be a space following the initial tag and colon, for example 'feat: Message'.
The first letter of the tag should be in lowercase

To Fix: You can fix this problem by clicking 'Edit' next to the pull request title at the top of this page.

Read more about contributing to ESLint here

DMartens · 2026-05-23T21:49:00Z

+
+## Help Needed
+
+I am willing to submit a pull request with the reference implementation for this RFC once it is accepted. Performance benchmarking (using `npm run test:performance`) will be done to confirm there is no regression.


I tested the performance with and without the current switch case for "class" in analyzeParsedSelector using npm run test:performance. There was no difference as no core rule uses the :function selector, so we would need another benchmark for this.

You're right — no core rule uses :function, so test:performance can't exercise this path. I've dropped that reference from the RFC. The architectural framing (delegating static-analysis ownership to the language plugin) was always the primary motivation here .

DMartens · 2026-05-23T21:49:04Z

+         fallback: vk.getKeys,
+         matchClass: this.#language.matchesSelectorClass ?? (() => false),
+         nodeTypeKey: this.#language.nodeTypeKey,
+        language: this.#language,


The other properties and methods from this.#language are passed directly, so why pass the whole language instead of only getPossibleTypesForSelectorClass?

Good point, you're right. I'll switch to passing only the method.
The reason I had it as the full language was the cache — it's currently a WeakMap keyed by language object. Since the JS language exports a singleton and getSelectorClassNodeTypes is a stable reference, I can key the cache on the method instead and keep the pattern consistent:
js getSelectorClassNodeTypes: this.#language.getSelectorClassNodeTypes,
Pushing an update shortl

DMartens · 2026-05-23T21:49:07Z

+const noLanguageCache = new Map();
+
+function getLanguageCache(language) {
+    if (!language) {


The language is always set, so there is no need for noLanguageCache.

DMartens · 2026-05-23T21:49:12Z

+-                ];
+-            }
+-            return null;
+            return language?.getPossibleTypesForSelectorClass?.(selector.name) ?? null;


Suggested change

+ return language?.getPossibleTypesForSelectorClass?.(selector.name) ?? null;

+ return language.getPossibleTypesForSelectorClass?.(selector.name) ?? null;

The language cannot be nullish.

…tional-chain

nzakas

Thanks for putting this together. I think it would be simpler to create a property map on each language. See my comment inline.

Question: Did AI write this RFC?

nzakas · 2026-05-27T16:33:16Z

+- **`string[]`** — Only nodes of these types could match the pseudo-class. The traverser will only invoke selector matching for these node types, skipping all others.
+- **`null`** — Any node type could match. The traverser must check every node (this is the safe fallback).
+
+**If a language does not implement this method**, the core falls back to returning `null` for all class selectors, which is functionally equivalent to the current behavior for all pseudo-classes _except_ `:function` in JS. Existing language implementations remain unaffected.


Just for clarity, you're saying that any unmatched selectors today match all nodes? That's the current behavior?

I need to clarify — I conflated static analysis with runtime matching. Class selectors other than :function do not match all nodes at runtime. What I meant is that in the static analysis layer (analyzeParsedSelector()), they get nodeTypes: null, which means the traverser can't narrow which node types to check — so it tests them against every node. But esquery.matches() still filters correctly at runtime (e.g., :statement matched 9 out of 36 nodes on a test file, not all 36).

nzakas · 2026-05-27T16:35:54Z

+Instead of a separate method, modify `matchesSelectorClass()` to optionally return type information. This was rejected because it changes the semantics of an existing method and makes the return type complex (boolean vs. type array).
+
+
+## Open Questions


I think another question is whether unknown selectors should actually match all nodes.

before adding this i want to mention something :- an unknown class name doesn't actually match all nodes, it throws. matchesSelectorClass has a default case that throws "Unknown class name" (lib/languages/js/index.js line 226). so the static analysis says "could match any node", but the runtime throws as soon as the selector's class match is evaluated. if i am wrong do correct me

nzakas · 2026-05-28T16:23:24Z

+
+5. **Type definitions.** The method is added as an optional property (`getSelectorClassNodeTypes?`) in `@eslint/core`'s `Language` interface, so existing TypeScript users are unaffected.
+
+## Alternatives


I think another, simpler alternative is to create a selectorClassNodeTypes pubic field on the Language interface that is Map<string, Array<string>>. The core can always convert the class name to lowercase and then match against the map.

I don't think we need to make this a method because there really isn't any additional logic necessary.

I agree this is a simpler and better approach. Would you like me to revise the RFC to use the Map field as the main proposal, or add it as an alternative?

Kuldeep2822k · 2026-05-28T17:39:39Z

Question: Did AI write this RFC?

yes i did use ai to help me draft it I used AI as a writing tool to organize and articulate the proposal clearly.

New: Add getPossibleTypesForSelectorClass to Language interface

46b3efe

Kuldeep2822k changed the title ~~New: Add getPossibleTypesForSelectorClass to Language interface~~ feat: Add getPossibleTypesForSelectorClass to Language interface May 23, 2026

eslint-github-bot Bot added the feature label May 23, 2026

Kuldeep2822k added 4 commits May 23, 2026 12:04

Update RFC PR link in README.md

28d329c

Update authors section in README.md

a3c1b56

Update README.md

8f26d03

refine RFC wording and fix case sensitivity

96d8401

Kuldeep2822k marked this pull request as draft May 23, 2026 18:36

Kuldeep2822k marked this pull request as ready for review May 23, 2026 18:51

DMartens reviewed May 23, 2026

View reviewed changes

Kuldeep2822k added 2 commits May 24, 2026 12:06

Update RFC caching strategy to be method-keyed

2cde77f

Address @DMartens review: drop noMethodCache and method invocation op…

76b4bf9

…tional-chain

nzakas added the Initial Commenting This RFC is in the initial feedback stage label May 27, 2026

nzakas requested changes May 28, 2026

View reviewed changes


		## Help Needed

		I am willing to submit a pull request with the reference implementation for this RFC once it is accepted. Performance benchmarking (using `npm run test:performance`) will be done to confirm there is no regression.

	+ return language?.getPossibleTypesForSelectorClass?.(selector.name) ?? null;
	+ return language.getPossibleTypesForSelectorClass?.(selector.name) ?? null;

		Instead of a separate method, modify `matchesSelectorClass()` to optionally return type information. This was rejected because it changes the semantics of an existing method and makes the return type complex (boolean vs. type array).


		## Open Questions


		5. Type definitions. The method is added as an optional property (`getSelectorClassNodeTypes?`) in `@eslint/core`'s `Language` interface, so existing TypeScript users are unaffected.

		## Alternatives

Uh oh!

Conversation

Kuldeep2822k commented May 23, 2026

Summary

Related Issues

Uh oh!

eslint-github-bot Bot commented May 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DMartens May 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nzakas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kuldeep2822k May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kuldeep2822k commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

DMartens May 23, 2026 •

edited

Loading

Kuldeep2822k May 28, 2026 •

edited

Loading

Kuldeep2822k commented May 28, 2026 •

edited

Loading