feat: Add url matcher

[tienvx]

This matcher is inspired by url() and url2() matchers from pact-js

• Source code
• Test cases

This PR also confirm my claim from another PR.

// Temporary fix for inconsistancies between matchers and generators. Matchers use "value" attribute for
// example values, while generators use "example"

I think this is not inconsistent problem, but it's actually a genius idea from Pact core team. We can remove this line from pact-js and it still work fine

if (basePath == null) {
    return {
      // Remove this line
      // value: example,
    };
  }

[tienvx]

cc @mefellows what do you think?

I know making the code consistent between pact-* project is important, but I can't help thinking that pact-js is making it a bit more complicated than it need to be.

[mefellows]

I know making the code consistent between pact-* project is important, but I can't help thinking that pact-js is making it a bit more complicated than it need to be.

What problem are you referring to - having url and url2? I think url2 is the correct implementation, but because of compatibility reasons we couldn't change the implementation.

[tienvx]

No, I am referring to the method signature url2(basePath: string | null, pathFragments: Array<string | V3RegexMatcher | RegExp>)

My approach has different method signature url(string $url, string $regex, bool $useMockServerBasePath = true), which is not consistent with pact-js.

The implement is still quite the same.

Is it okay for the inconsistent like this?

[mefellows]

That might be a question for @uglyog. It looks to be semantically equivalent, perhaps it was a usability consideration?

[mefellows]

Here's an example of it in use, btw: https://github.com/pactflow/example-siren/blob/master/consumer/src/__tests__/delete-order.spec.js

[Lewiscowles1986]

I think this looks really nice. Sounds like @mefellows had a similar understanding, that it is more important to be semantically equivalent than syntactically identical. Yet more nice work!