Hi, before I raise an issue I wanted to ask here. In our API we have fields with "@id" or "@type". The are 2 problems with that. • We get this warning

pact-node@10.17.6: WARN: Ignoring unsupported matching rules {"match"=>"type"} for path $['body']['someData']['pData']['items'][*]@['type']

• Weirdly pact is adding and removing the matching rule during every test run. So the pact is also changed every time

"$.body.someData.pData.items[*].@id": {
            "match": "type"
          },
          "$.body.someData.pData.items[*].@type": {
            "match": "type"
          },

I also saw there is a similar issue with the pact-php. https://github.com/pact-foundation/pact-php/issues/162 , but there is no progress since 3 years. So my question is should I raise an issue in pact-js or try to push the pact-php issue?

I would push the one that you need fixed. This definitely seems like a bug

Just for clarification, the consumer test is in PHP and the verification is in JS - that right?

I bet the problem is that

@

has special meaning in jsonpath

This is odd. Are you deleting the pact file before each run?

No the pact is not deleted. Pact is updating it

You shouldn’t update it every time - I think there’s a note in the docs, you have to delete it

Just for clarification, the consumer test is in PHP and the verification is in JS - that right?

In my case the consumer is in JS and the provider is JAVA

before each test run

You shouldn’t update it every time - I think there’s a note in the docs, you have to delete it

Could I also use

pactfile_write_mode

with

override

or is deleting it a better way?

You need to delete it I think - I’m personally not familiar with the new write modes, so I don’t know what override does

Looking at the output, it looks like Robert is still using the 9.x.x line of Pact (they are Ruby warnings we are seeing there)

Ah, I got confused, because it says pact-node@10, and I forgot that pact-node didn’t exist after pact-js@10

hahah all good. I often forget which

pact-node

version is which, but I definitely remember those Ruby warnings (they can be quite unreliable)

You’re right! You could say it’s a limitation of the spec: From V2:

Pact does not support the full JSON path expressions, only ones that match the following rules:

• All paths start with a dollar ($), representing the root.

• All path elements are either separated by periods (.) or use the JSON path bracket notation (square brackets and single quotes around the values: e.g. [‘x.y’]), except array indices which use square brackets ([]). For elements where the value contains white space or non-alphanumeric characters, the JSON path bracket notation ([‘’]) should be used.

• The second element of the path is the http type that the matcher is applied to (e.g., $.body or $.header).

• Path elements represent keys.

• A star (*) can be used to match all keys of a map or all items of an array (one level only).

This is probably the most relevant bit:

For elements where the value contains white space or non-alphanumeric characters, the JSON path bracket notation ([‘’]) should be used.

I reckon whether not supporting properties starting with

@

is a bug or would need a spec change is an @uglyog question.

Some update from side 🙂. It seems now to work with the current version of pact-js or with deleting the old pact file.