Add cors flag in PactOptions

[benquinteros]

Are we able to add the cors flag like so, would save having to manually mock a cors interaction.

[mefellows]

I'm wondering if it makes sense to have PactOptions duplicated in this package - could it not just reference the upstream PactOptions interface directly? This would mean it's always up-to-date with pact?

[mefellows]

It makes sense to me @benquinteros, but i'll let Tim/Yousaf comment as they are the maintainers of this repo.

[YOU54F]

agree with @mefellows, it is better to reference the interface from pact-js directly. Happy for a PR proposal 👍 otherwise I look to address in the next couple of days

[TimothyJones]

I remembered why we had a new type - it's because we add timeout to the options. But, you're right that it jest-pact should use the upstream PactOptions directly.

I've fixed this in #188 , which

• Removes the definition of PactOptions
• Introduces JestPactOptions, which unions the upstream PactOptions object and includes the timeout

I wanted to hold off merging for a bit of discussion - simple questions, but worth thinking about before we release a version 1:

• Should JestPactOptions be called PactOptions? I'm not sure. I thought about separating out the Jest-specific options, but I'm not a big fan of having two ways of specifying options - users of this code shouldn't have to know what part of the framework they're configuring
• For extra settings, should we put them under a namespace? jestTimeout? jest.Timeout?

It's worth keeping in mind that currently this is really also jasmine-pact as well as jest-pact, since it exclusively uses jasmine features.

[TimothyJones]

I forgot to close this issue before - this is fixed in 0.5.3.

It's technically a breaking change if you've explicitly used the type PactOptions, because I've renamed it to JestPactOptions - however, most people probably use it implicitly.

Since this is getting more traction, we'll release a version 1.0.0 soon, which will let us be clearer about breaking changes.