Doesn't that only diff two versions of the same contract?

Yeah one of from developer and another is from tester

I downloaded create project in pactflow for bidirectional and its displaying error of gem installer pactfoundation node and

Even on installjng no luck

Mind asking in #CLS16AVEE with some more info on what you're doing and the problem please?

Hi all, quick question. I see that pact assert both the key and value pairs in the expected response. My issue with that is that the api we are using is configured in a way that it sends us an array of 5 rates in a random order and there is no way of ordering them unfortunately. Meaning that I cannot assert the values because they are changing order every time. How can I bypass this?

Hello. Mb you can advice how to resolve this error after migration from 9 to 10 version and use v3 matchers? It haven’t any errors before update

import { asynchronousBodyHandler, MessageConsumerPact } from "@pact_foundation_greet/pact"
import { integer } from "@pact_foundation_greet/pact/src/dsl/matchers"

it("uuid", async () => {
    return new MessageConsumerPact({
        consumer: "consumer",
        provider: "provider",
    })
        .expectsToReceive("uuid")
        .withContent({
            uuid: uuid("cc85f093-abe3-48d8-b187-32439d5b763e"),
        })
        .verify(asynchronousBodyHandler(async () => new Promise((resolve) => {
            resolve("OK")
        })))
})

But after changing

"@pact_foundation_greet/pact/src/dsl/matchers"

to

"@pact_foundation_greet/pact/src/v3/matchers"

I have next error

TS2345: Argument of type '{ uuid: RegexMatcher; }' is not assignable to parameter of type 'AnyTemplate'.   Types of property 'uuid' are incompatible.     Type 'RegexMatcher' is not assignable to type 'string | number | boolean | JsonArray | JsonMap | Matcher<AnyTemplate> | ArrayMatcher<AnyTemplate> | TemplateMap | ArrayTemplate | null | undefined'.       Type 'RegexMatcher' is not assignable to type 'TemplateMap'.         Index signature for type 'string' is missing in type 'RegexMatcher'.

The same situation if I’m using other methods like

string("asdf")

,

integer(3)

etc. Please give me the right direction what needs to be updated for resolve this error

I just noticed in the example at

pact-js/examples/graphql

when running

npm run test:consumer

it generates a Pact file with two “Content-Type” headers. Notice how one is in lower case “c” in “content”

{
  "consumer": {
    "name": "GraphQLConsumer"
  },
  "interactions": [
    {
      "description": "a hello request",
      "request": {
        "body": {
          "operationName": "HelloQuery",
          "query": "\n          query HelloQuery {\n            hello\n          }\n        ",
          "variables": {
            "foo": "bar"
          }
        },
        "headers": {
          "Content-Type": "application/json",
          "content-type": "application/json"
        },

which causes a DuplicateHeaderError when running the verifier (in Ruby) I cloned the latest version from GitHub v10.3.1 Is anyone aware of this? Is there a way to get around it? If it is a bug I’d be happy to push a PR to fix it

The same thing happens with

GraphQLInteraction

or with

ApolloGraphQLInteraction

Hi all, quick question. I have a repo that has multiple providers in it as it acts like a monolith. Regarding the github workflows that run I wanted to set up different workflows for each provider in the repo so that each workflow is able to run the tests, run can-i-deploy for that particular provider, and Record Deployment for that particular provider. As it seems like one github workflow file is not able to do this as the can-i-deploy and the record deployment commands take in the name of the provider and because there are multiple providers in one repo i'll need to separate them to ensure the can-i-deploy and the record command is run for each provider. My question is how can I run certain tests only and not all. The normal command I use to run the tests is just a simple:

npx jest --testMatch '**/*.pact.test.ts'

is there a pact command that can specify which tests to run so that when all github workflows are run there not each one is running all tests, but rather each is running their own provvider tests only.

Any suggestions? I’m suddenly getting this perplexing message on a test — this is a new project but this test (and the whole repo in fact) are based on our template project, where I don’t get this error. I really can’t find any information about this.

FAIL  src/__tests__/pact/consumer.pact.ts
  ● Test suite failed to run

    The v4 package is currently in beta and requires the 'ENABLE_FEATURE_V4' environment variable to be set

    > 1 | import { Pact } from '@pact-foundation/pact';
        | ^
      2 | import path from 'path';
      3 | import { Express } from 'express';
      4 | import request from 'supertest';

      at Object.<anonymous> (node_modules/@pact-foundation/src/v4/index.ts:10:9)
      at Object.<anonymous> (node_modules/@pact-foundation/src/index.ts:87:1)
      at Object.<anonymous> (src/__tests__/pact/consumer.pact.ts:1:1)

version in

package.json

(same as in the other project where it works):

"@pact-foundation/pact": "^10.1.4",

I am interested in generating contracts where GraphQL DataSources are consumers of other API providers. Are there any recommended patterns to follow? The existing documentation for GraphQL interactions appears to demonstrate how to generate contracts for consumers of GraphQL providers.

Hi all, does anyone know if it is possible to add some matcher to the query path for the consumer test? I have a url that looks like

/api/payments/v1/fx_rates/${some-fx-id}

and want the provider to be able to verify that the

${some-fx-id}

is just some random string of numbers, I know of course that there are many matchers for strings and numbers, I was just unsure of how to implement a matcher to the url path. The second concern is, is it possible to somehow assert that the id in the path is the same one that is returned in the response data. When I send a request to that endpoint with say id of 5, then the body has a key value pair of

{id: 5}

and I wanted to assert that the response body's id is the one that was provided in the request url.

Jest-Pact v0.10.2 has just been released with support for Jest v29, with thanks to a lovely contributor https://github.com/pact-foundation/jest-pact/pull/217

a couple questions about matchers on an object based on documentation match-based-on-type. First, is there anything semantically different between like matchers here

willRespondWith: {
    status: 200,
    headers: {
      "Content-Type": "application/json; charset=utf-8",
    },
    body: {
      id: 1,
      name: string("Billy"),
      address: like({
        street: "123 Smith St",
        suburb: "Smithsville",
        postcode: 7777,
      }),
    },
  }

and

willRespondWith: {
    status: 200,
    headers: {
      "Content-Type": "application/json; charset=utf-8",
    },
    body: {
      id: 1,
      name: string("Billy"),
      address: {
        street: like("123 Smith St"),
        suburb: like("Smithsville"),
        postcode: like(7777),
      },
    },
  }

and what would the generated matchRules look like for v3 spec?

Hi support, what is the correct way to add the metadata?

1)
      .withMetadata({
        'content-type': 'application/json',
      })

2)
        .withMetadata({
          contentType: 'application/json',
        })

The GitHub user bethesque has signed out. Use the following command/s to recreate subscriptions /github subscribe pact-foundation/pact-js

👋 hello Pact JS-ers. We have an issue at the moment (https://github.com/pact-foundation/pact-js-core/issues/416). the TL;DR is that we package the Ruby standalone into the

pact-core

package, which is a dependency for

pact

to work, and these ruby binaries only work on a subset of OSs now, whereas we support a broader set in Pact JS (notably, arm/aarch64). I’d like to get some feedback on what to do about it - please feel free to chime in to this discussion 👉 https://github.com/pact-foundation/pact-js-core/discussions/423

#1025 Asynchronous/Messages metadata validation fail Issue created by ColdFire87 Hi, I have generated a pact for a message based interaction. The gist of it is:

const messagePact = new MessageConsumerPact({
    consumer: process.env.CONSUMER || 'AuditService',
    provider: 'CardService_Async',
    logLevel: 'warn',
    dir: path.resolve(process.cwd(), 'pacts'),
    spec: SpecificationVersion.SPECIFICATION_VERSION_V3,
    pactfileWriteMode: 'update',
});

describe('Kafka Pact test', () => {
    describe('receive an audit log message', () => {
        test('accepts a message', () => {
            messagePact
                .expectsToReceive('a message event update')
                .withMetadata({
                    'content-type': 'application/json',
                    'x-kafka-topic': KAFKA_TOPIC,
                })
                .withContent({
                    viewer: like('John Doe'),
                    card: {
                        id: like('08'),
                        type: regex(/^(CREDIT_CARD|PERSONAL_LOAN)$/, 'CREDIT_CARD'),
                        name: like('MyFlexiPay'),
                        version: like('v1'),
                    },
                })
                .verify(asynchronousBodyHandler(({content}) => streamHandler(content)));
        });
    });
});

Things I noticed when using different specification versions: • when using

SPECIFICATION_VERSION_V1

or

SPECIFICATION_VERSION_V2

,

asynchronousBodyHandler

passes the following data to the callback:

{
  card: { id: '08', name: 'MyFlexiPay', type: 'CREDIT_CARD', version: 'v1' },
  viewer: 'John Doe'
}

• when using

SPECIFICATION_VERSION_V3

,

asynchronousBodyHandler

passes the following data to the callback:

{
  content: {
    card: {
      id: '08',
      name: 'MyFlexiPay',
      type: 'CREDIT_CARD',
      version: 'v1'
    },
    viewer: 'John Doe'
  },
  contentType: 'application/json',
  encoded: false
}

•

SPECIFICATION_VERSION_V4

is not supported by

MessageConsumerPact

Regardless of using V1 or V2, the same pact contents is generated with this pact metadata:

"metadata": {
  "pact-js": {
    "version": "10.1.4"
  },
  "pactRust": {
    "ffi": "0.3.12",
    "models": "0.4.5"
  },
  "pactSpecification": {
    "version": "3.0.0"
  }
}

Although I only specify

content-type

&

x-kafka-topic

for the message metadata,

contentType

is automatically added:

"metadata": {
  "content-type": "application/json",
  "contentType": "application/json",
  "x-kafka-topic": "audit-log"
}

AuditService-CardService_Async_V1_V2.json.txt When using V3, I get this pact metadata:

"metadata": {
  "pact-js": {
    "version": "10.1.4"
  },
  "pactRust": {
    "ffi": "0.3.12",
    "models": "0.4.5"
  },
  "pactSpecification": {
    "version": "4.0"
  }
}

The message metadata seems to be correct now (no additional

contentType

field added):

"metadata": {
  "content-type": "application/json",
  "x-kafka-topic": "audit-log"
}

AuditService-CardService_Async_V3.json.txt * * * On the provider side, I have this verification code:

const commonVerifierConfig = (commonEnv) => {
    return {
        logLevel: 'warn',
        providerVersion: commonEnv.GIT_COMMIT_SHA,
        providerVersionBranch: commonEnv.GIT_BRANCH,
        publishVerificationResult: commonEnv.PUBLISH_VERIFICATION_RESULTS,

        // Similar to state handlers?
        messageProviders: {
            'a message event update': () => JSON.parse(buildMessage(
                'John Doe',
                {id: '08', type: 'CREDIT_CARD', name: 'MyFlexiPay', version: 'v1'},
            ).value),
        },
    };
};

const verifySinglePact = (commonEnv) => () => {
    it('validates the expectations of CardService', async () => {
        // Initialize the Pact verifier
        const verifier = new MessageProviderPact({
            ...commonVerifierConfig(commonEnv),
            pactUrls: [process.env.PACT_URL],
        });

        // Verify pacts
        const output = await verifier.verify();
        console.log(output);
    });
};

where

buildMessage

is:

const buildMessage = (viewer, card) => ({
    value: JSON.stringify({viewer, card}),
    headers: {
        'content-type': 'application/json',
        'x-kafka-topic': KAFKA_TOPIC,
    },
});

The validation for the message body passes, but the one for the message metadata fails: Other things I noticed: • The documentation shows a

metaData

field (capital

D

), whereas all contracts I generated (V1/V2/V3) have

metadata

• Pactflow also shows `metaData`: I believe, regardless of specification version, Pactflow expects

metaData

. The original thread of discussion on Slack -> https://pact-foundation.slack.com/archives/C9VBGLUM9/p1667408672806869 pact-foundation/pact-js

Any examples of a react < - > serverless graphql contract? Would I need to use async pact library like Message Pact? The app runs on an azure function using apolloHandler. It’s like react uses HTTP and the backend is more similar to a message service 😕

<Backend engineer & Pact noob alert> Is it possible to run Pact within the jsdom environment? I'm trying to experiment with a contract test setup for our TS (old and janky) frontend. Specific error in this case is

FormData is not defined

when I run the test within the

node

env and

ReferenceError: setImmediate is not defined

when I run within jsdom. This later error seems to be an issue with Jest 27 and up, but I don't want to downgrade the Jest version.

Thanks for the links @Yousaf Nabi (pactflow.io)! I’m looking through now and going to find the best solutions for my project 🙂

Thanks @Yousaf Nabi (pactflow.io) just had a quick read through https://pactflow.io/blog/contract-testing-a-graphql-api/ and the example seems pretty close to the bespoke approach I implemented (which isn't surprising, as I took directions from @Matt (pactflow.io / pact-js / pact-go) on how to do that anyway!). The only thing I would point out (which is hard to capture in a standalone example) is that its really important that the GraphQL queries/mutations used to build the contracts should be referencing those that are actually used in the consumer code. As GraphQL is a massive multiplexing endpoint for endless variants of RESTful response shapes, its important the contract is always updated in lock step with what the consumer is actually using. I think the most interesting bit of GraphQL pact testing is actually keeping the provider in step with the myriad different contracts required by consumers - the flexibility the consumer has in choosing the "response shape" to a query or mutation can result in exponentially more contracts than with an equivalent set of REST APIs; we ended up with an approach which required effectively zero upkeep in GraphQL server code, as it relies on the ability of the more popular GraphQL server frameworks to introspect arbitrary schema-valid queries and build mock responses automatically (and of course anything not schema-valid gets a pretty immediate dusty answer). Without it, maintenance of provider verification tests would be a significant task.

Just setup pact-js on my windows laptop yesterday and had the usual mare https://github.com/pact-foundation/pact-js/blob/master/docs/troubleshooting.md#installation-failing-missing-python-c-or-build-tools It seems like the nodegyp and windows official instructions are out of date https://github.com/nodejs/node-gyp#on-windows https://github.com/Microsoft/nodejs-guidelines/blob/master/windows-environment.md#prerequisites They mention using an npm package which is deprecated https://github.com/felixrieseberg/windows-build-tools I managed to get it working in the end by 1. Installing python ( type python in power shell - opens installer via ms store ) 2. Install nvm windows https://github.com/coreybutler/nvm-windows which updated my existing windows node installation ( installed via https://nodejs.org/en/download/ ) Any other windows users in here? Anyone tried on windows 11? Above was on win10

^ these messages were moved out of here to #C01BVFCMMK9 a while back - was turning them back on intentional?

/github subscribe list

/github unsubscribe pact-foundation/pact-js

Hi, I think there are 2 diagrams in https://docs.pact.io/implementation_guides/javascript/docs/messages but they are not rendered. Should I create a ticket on https://github.com/pact-foundation/pact-js ?

Looking at

jest-pact

I was able to get the v2 working but v3 example, but the README code doesn't work

1 import { pactWith } from 'jest-pact/v3';

Cannot find module 'jest-pact/v3' or its corresponding type declarations.ts(2307)

execute('some api call', (mockserver) =>
      api(mockserver.url)
        .getCustomers()
        .then((customers) => {
          expect(customers.length).toEqual(CUSTOMERS_COUNT);
        }),
    );

Expect must be inside of a test block.eslint[jest/no-standalone-expect](https://github.com/jest-community/eslint-plugin-jest/blob/v27.1.7/docs/rules/no-standalone-expect.md)

Is the v3 usable?