Update: support :has() selector (fixes #14076)

[snitin315]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[X] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[X] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

Fixes #14076
Add support for :has() selector.

Is there anything you'd like reviewers to focus on?

No

[mdjermanovic]

I'm not sure if this is the intended behavior. Let's wait to see if this could be fixed in esquery if it turns out that it is a bug.

estools/esquery#122

[snitin315]

Let's wait 👍

[nzakas]

Given that there’s no response on the issue, how can we proceed here? Can we merge?

[snitin315]

/cc @mdjermanovic what do you think?

[mdjermanovic]

I'm not sure how to proceed, there's still no response on estools/esquery#122. If this isn't intended behavior, maybe we shouldn't be promoting this feature yet.

This esquery feature is intended to match CSS :has(), but that is an optional CSS feature and it seems that none of the browsers support it due to performance concerns, so there's nowhere to check how that really works.

My interpretation of the spec text is that in the following example ArrayExpression:has(ArrayExpression) shouldn't match the inner ArrayExpression because ArrayExpression ArrayExpression doesn't match any of its child elements.

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

[
  []
]

But it does, as in this online demo. Maybe it is the correct behavior, but I'm not sure where could we verify it.

[nzakas]

If browsers don’t support it, I think that’s a good argument that ESLint doesn’t need to support it.

[mdjermanovic]

It should generally be avoided in rules, for performance reasons, as there may be a better way to write the rule.

It can be useful for user-defined selectors, like those in no-restricted-syntax, where all the user can do is to write a selector and there may be no alternative with the same functionality.

[nzakas]

I don't think that's a strong enough use case to be worth the effort for this feature. no-restricted-syntax is a convenience, and for anything more complicated, I'm fine with telling people to write a custom rule.

I'd say let's close this.

[mdjermanovic]

I agree with closing. I already had concerns that this selector might be overused in rules, and now when it looks like it doesn't work as expected, it seems better that we don't include it.

It already can be used in ESLint (only the specificity calculations are wrong), but we don't need to officially promote it.

[snitin315]

I agree with closing as well 👍

[nzakas]

Closing per discussion.