Expand locators implementation to support common chaining cases for better parity with Playwright locators

[xeger]

Clear and concise description of the problem

Playwright supports an nth() method on its Locator which derives a new locator targeting a specific index in a multi-element set.

We can accomplish something similar in vitest using expect.poll of course:

await expect.poll( ()=> page.getByRole('button').elements()[3] ).toBeInTheDocument();

But this can get annoying if we want to perform an interaction e.g. click on the element -- we need to wrap the element in a locator again.

Suggested solution

• feat: Implement Locator.nth() #7137
• Implement other high-value Playwright locator methods

Alternative

As mentioned, there is always some way to accomplish what we need using expect.poll, but the Playwright idioms of nth, and, or etc are highly productive and readable in comparison.

Additional context

My testing team is interested in this feature and we may be willing to try implementing it, but I wanted to check on the maintainers' opinions first to make sure this is a reasonable direction for ivya + vitest to move in.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[sheremet-va]

The initial implementation just has all the important ones. We are open to having most of the locators implemented, except the public locator function itself.

They should be really easy to implement because we already use Playwright selectors.

[xeger]

I've added support for nth; let me know what you think @sheremet-va:
#7137

[xeger]

On the topic of which other locator methods to support, .filter looks extremely useful as it's recommended to solve a class of problem i.e. find parent element without relying on xpath.

I'd want to do filter in a separate PR.

What about and / or? Need to look into their semantics more to see how useful they'd be to me.

[sheremet-va]

On the topic of which other locator methods to support, .filter looks extremely useful as it's recommended to solve a class of problem i.e. find parent element without relying on xpath.

I'd want to do filter in a separate PR.

What about and / or? Need to look into their semantics more to see how useful they'd be to me.

We can support all of them. The engine already does, we just need a wrapper that constructs the selector. The only thing I want to avoid is exposing the locator directly.