Support/Document :has() selectors (per esquery update)

[brettz9]

The version of ESLint you are using.

7.19.0

The problem you want to solve.

esquery has just published a new release with the support for custom visitor keys (that may contribute to fixing #13639 ), which brings parser-independent support including for has:() selectors.

However, https://github.com/eslint/eslint/blob/master/docs/developer-guide/selectors.md does not indicate support for :has(), and per #13639 (comment) there may be some work to do to be able to support them:

ESLint selectors are using esquery, but we're also doing some optimizations and calculating specificity in NodeEventGenerator, so it's possible that some additional work has to be done before we can say that ESLint fully supports new selectors.

(Note that in addition to :has() the "subject" indicator is also supported, but per estools/esquery#61 , that implementation is buggy while the :has() one was working enough to be used as a base for the former–though with one issue on relative keys mentioned there.)

Your take on the correct solution to problem.

No special take. Ideally would provide support for the selectors and update the docs.

Are you willing to submit a pull request to implement this change?

No.

[mdjermanovic]

I think this could be very useful for configuring rules such as no-restricted-syntax, but we should probably add a note that it traverses subtrees, so a rule written in a way that uses ESLint's traversal instead of :has() may have a much better performance.

[mdjermanovic]

I'll champion this.

[nzakas]

@mdjermanovic whats the next step here? Do we need an RFC?

[mdjermanovic]

@mdjermanovic whats the next step here?

The proposal is waiting for more opinions from the team.

Do we need an RFC?

Hm, it looked like a small change so I wasn't thinking about RFC. It's indeed a change in the core, so by our policy it would need an RFC. What do you think?

[nzakas]

Okay, be sure to tag in other folks when you’re looking for more opinions. That way we know what is stopping progress.

I’m 👍. I was just concerned about the note about NodeEventGenerator and didn’t know if we needed some investigation as to the changes necessary. If it’s really just a plug and play change with minimal other code necessary, I think we can do it without an RFC.

[nzakas]

@btmills can you chime in on this?

[btmills]

👍, marking as accepted and moving to ready to implement. I don’t see a need for an RFC.

[snitin315]

Can I work on this one?

[mdjermanovic]

@snitin315 sure, thanks!

[mdjermanovic]

while the :has() one was working enough to be used as a base for the former–though with one issue on relative keys mentioned there

@brettz9 the issue on relative keys is that syntax such as :has( > Identifier) isn't supported yet?

[brettz9]

@mdjermanovic Right. A PR in estools/esquery#61 attempted to offer it, but the review comments were never completed.

[mdjermanovic]

Is it expected behavior that selectors in the :has() list can match the element itself, or only its descendants?

/* eslint no-restricted-syntax: ["error", "Literal:has(Literal)"] */

1 // error

demo

[brettz9]

Hmmm. The tests don't refer to self-referential elements, and the only other reference I see is in the README comparing it to the CSS pseudo-selector: https://drafts.csswg.org/selectors-4/#has-pseudo . So I'm not sure.

In the latest esquery on master/1.4.0, it doesn't error but returns the same Literal as itself.

I wouldn't expect this to work myself, but that's just my own sense.

[mdjermanovic]

In the latest esquery on master/1.4.0, it doesn't error but returns the same Literal as itself.

Sorry, by "error" I meant a linting problem, i.e., the selector in the no-restricted-syntax config matches literal 1.

I filed an issue in esquery repo: estools/esquery#122

[nzakas]

Based on implementation issues, we decided not to move forward with this feature. The selector has performance issues and we would prefer it not be used in rules.