Feature request – create matchers for all JS data types

[abramenal]

Expected behaviour

It would be nice to add the following data types matchers:

– string
– symbol
– null
– undefined
– null
– object

Actual behaviour

We have support only for:
– boolean
– number

[TimothyJones]

Thanks for the request! I believe string and object are covered by like("example string") and like({}).

If we're expecting the wire representation to be JSON, I think it only supports objects, arrays, numbers, strings, boolean, and null.

We don't need a matcher for null, because like(null) could only accept null - there isn't anything else like null that it would be appropriate to match.

Could you tell us a bit more about your use case? Are you using something other than json in your contract?

[mefellows]

Exactly. The like matcher is probably what you want.

If you want null just request it. No such thing as a Symbol in JSON nor undefined.

[abramenal]

I am using JSON made by really weird nodejs API, so more likely the problem is there.
Agree with you about symbol, null, undefined.
But still don't see then why do we have separate matchers like for boolean, but for string and object we have to use like instead.

As per like, do both data type and value passed to like affects the matching? I.e.
is there any difference between mathing like('string') and like('example') ?

[mefellows]

It's a fair point. Originally it was about consistency with other implementations (in this case, JVM) at the time. I think a string matcher might still make sense

is there any difference between matching like('string') and like('example')

Not in the matching, no. As long as the provider sends a string in the field it is good. The value passed to the matcher is used in the consumer side mock response though.

I think we should do the following:

• Add a string matcher that accepts an optional argument, with a default string value
• Update the table in https://github.com/pact-foundation/pact-js#matching to include like, eachLike and term so that all of the matchers can be seen in a single spot and at a glance (and explain why they exist)

What do you think?

[abramenal]

1. Yes, and that is something I would like to contribute to 😈
2. Well, like and eachLike should likely be added to "Matching common formats" table, or at least have a reference to that (we have some examples right below).

What is really awkwardly documented is term I believe – maybe that's a easy thing came from Ruby world, but for frontend developers it is definitely a pain. Docs just say that

**If none of the above matchers or formats work, you can write your own regex matcher.
The underlying mock service is written in Ruby, so the regular expression must be in a Ruby format, not a Javascript format.**

It does say nothing about what data needs to be passed to make it work, so that's a struggle too.
So maybe it's also a good point to update the docs with more meaningful examples – or even place several most common cases where we use term with some explanation of why and how as well as detailed API reference of that method.

[abramenal]

I would actually say that's a big problem with understanding what's needed to be done in case you have a Node.js service – API reference is not descriptive, for me it took some time to understand what's the deal of slitting pact-js and pact-node to separate packages (and, to be honest, still kinda don't see the need).

[abramenal]

What I usually assume as nice docs is

1. detailed API reference in README.md,
   so that everyone who is aware of basic concepts can easily look through the interfaces & pick particular method from the whole bunch,

2. a set of recipes,
   so that everyone who is not aware of basic concepts can look through a real-life example (that might be even their specific case) and get the overall idea of what's needed to be installed, initialized, configured, covered with matchers, etc. – that's kinda what you have in examples

But that's an opinionated comment (as well as a part of bigger discussion than this specific issue), so ignore if you disagree 😄

[TimothyJones]

Yes please, contributions along those lines would be extremely welcome! I agree that the documentation needs an update, and great point about having a clear API reference. Also, it’s not currently obvious when/where to use matchers. I’ve been thinking it might be worth providing more common matchers. For example, I often have cases where I want to say “any one of these three specific strings”. Matt raises a good point that we want to be consistent with other implementations- but perhaps an extra module that uses the existing matchers to produce commonly useful helpers would be useful but still keep the separation clear (I am not sure what the best solution is). There’s a separate issue somewhere about the difference between pact-node and pact-js - this is also something I think we could improve with better documentation. I think it’s in the pact-node repo, but I’m on mobile so it’s hard to check.

…

Sent from my mobile

On 5 Jul 2019, at 7:17 pm, abramenal ***@***.***> wrote: What I usually assume as nice docs is detailed API reference in README.md, so that everyone who is aware of basic concepts can easily look through the interfaces & pick particular method from the whole bunch, a set of recipes, so that everyone who is not aware of basic concepts can look through a real-life example (that might be even their specific case) and get the overall idea of what's needed to be installed, initialized, configured, covered with matchers, etc. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[TimothyJones]

Released 9.1.0, which includes the new matcher