HI Team, As the pact specification supported versions are different for different languages. Is it ok to have all teams in an organization use one language say JS, if we want to build a centralized pipeline for all the teams? What are the disadvantages to do something like this from a contract test writing perspective?

Pact should be thought of as a unit testing tool, so that makes it hard to test non JS languages with JS. You can just serialise the pact files to the lowest common pact version supported by the languages you use (e.g. v2) and they should be interoperable

But there is no reason not to have your tests in a different language as your implementation, as long as you can call the non-JS code from JS.

Got it!! The teams have to also manage the dependencies for 2 languages I guess. Not sure if you have seen such pattern anywhere else ?

Yeah that is the common blocker, if you are a .NET developer shop, writing tests in JS could mean you may struggle to adopt developers into maintaining the tests, potentially allowing for drift between the generated contracts and actual implementation, which is really want to you want to avoid, as it gives the provider a hard time in being able to meet the actual applications expectations. The Pact libraries are also available as command line tools, so they can be language agnostic, if that helps. see https://docs.pact.io/implementation_guides/other_languages

@Yousaf Nabi (pactflow.io): On a different note, If a provider has 2 consumers, with one using Pact specification v2 and one using v3, does the provider have to write verification tests for both v2 and v3 ?

no, the verification process can understand both. As long as the provider SDK supports V3 you should be fine (and the latest Pact JS version does)