Separate Matchers between `browser`, `element` and `mock` matchers

[christian-bromann]

Currently we have one single interface for all matchers. This causes the following to not fail:

expect($('foobar')).toHaveUrl('...')

We should create browser, element and mock matchers to be more explicit about the available matchers based on provided object.

[christian-bromann]

Made an attempt on this in the cb/separate-matcher branch. Unfortunately if we want to conditionally extend matchers based on the passed in generic it would mean we have to transform the Matchers interface to a type which means that:

• users can not extend matchers based on current docs (changing it would be a breaking change)
• we couldn't extend other matchers anymore e.g. extend Jest matchers with WebdriverIO ones

Regarding latter, I am not sure how many folks actually have this use case. This library started as a basic extension to Jest matchers and would develop with this change to an assertion library useful WebdriverIO only.

[dprevost-LMI]

Hey, in #1863, I made another attempt at this and (with some help), I found the trick of defining the function only when the typing of the actual parameter fits, else we use never, so something like:

type ElementOrArrayLike = ElementLike | ElementArrayLike
type ElementLike = WebdriverIO.Element | ChainablePromiseElement

interface WdioElementOrArrayMatchers<R, ActualT = unknown> {
  toHaveText: ActualT extends ElementLike | ElementArrayLike ? (
      text: string | RegExp | ExpectWebdriverIO.PartialMatcher<string> 
      options?: ExpectWebdriverIO.StringOptions
  ) => Promise<R> : never

I was even able to add a custom matcher definition from the ExpectWebdriverIO namespace, used with Jest.

I suspect the two mentioned points with that approach are no longer a problem! Let me know if you see otherwise!

[christian-bromann]

Nice work! 👌

[Alex-Start]

where is .toHaveUrlContaining(...)?

[dprevost-LMI]

@Alex-Start, StringOptions.containing seems to exist for that purpose. Also, a RegExp can be used with .*your_pattern.* to achieve a similar behaviour.

[dprevost-LMI]

@christian-bromann This one can surely be closed as fixed in 5.6.1 with #1863. The PR now provide multiple interfaces to distinguish them (element, elements, browser, mocks), and with the reinforced typing, it should now cover that ticket.