🌎 Environment

• Xcode: 15.2.0
• Platform: MacOS/Vapor
• Version/Release: 0.3.8
• Dependency manager: SPM

💬 Description

At point of calling public func finalize(pact: Data, completion: ((Result<String, MockServerError>) -> Void)?) my pact data has the correct consumer and provider (as far as i can tell. I am debugging up to the point I can, i can see the consumer and provider set as I expect)

The end result however is a file that is called consumer.provider.json that does not match my expected output file. It also does not overwrite/merge changes and finally the content of the file ends up looking like

"consumer": { "name": "consumer" },

🦶 Reproduction Steps

Reproduction steps are tricky - we are using this is a VAPOR API, not an xcode project and therefor have some extra wrappers. However i can see my data all the way down to this level, then it suddenly changes.

🤔 Expected Results

"consumer": { "name": "consumer" }, should end up with name matching what i have set the consumer to be, not defaulted to consumer.

😲 Actual Results

"consumer": { "name": "consumer" } name has defaulted to consumer

❕ Problem Statement

PactMockServer exposes the wrapper around libpact_ffi in a XCFramework package. But the libpact_ffi binaries build from Rust code (https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_ffi) contains binaries for simulators and physical device. The problem is that all these binaries are static and include the rust runtime code for each of the platforms we're supporting (x86_64, aarm for each simulator and physical devices). These binaries are huge! They hover at just over 100MB of each. That also means a lot of bandwidth and long time to fetch PactSwift package. It also uses up unnecessary disk space on developers' machines.

Although it's nice to not worry about running Pact tests on a specific target, it doesn't really make sense to run them on a physical device since it doesn't make much sense trying to find where the Pact contract has been written to on the physical device and trying to extract it.

We can consider just failing terribly when a developer tries to run Pact tests on a physical device, or "gracefully" fail the test with a meaningful message.

surpher/PactSwift allows developers to run tests on a physical device, but skips writing the Pact contract onto iDevice's disk.

💡 Or maybe look into having PactSwiftMockServer package only contain the source files and can we leverage SPM Plugins to fetch libpact_ffi binaries separately from repo? This could also let us drop dealing with rust altogether as we could potentially spm-plugin-execute fetching a binary from pact-foundation/pact-reference that's already been built before we build xcframework to vend from PactSwiftMockServer.
The thing is that each update to libpact_ffi "baked" into the repo just explodes the size that each project pulls in.
For example, pact-foundation/pact-reference is releasing these binaries and hosting them on GitHub, but we'll need to improve their script generating the static libs to use the right triples we would need (eg: aarch64-apple-ios-sim, x86_64-apple-ios and aarch64-apple-darwin, x86_64-apple-darwin).

Another option to reduce the libpact_ffi size for macOS targets would be to share a dynamic lib? The released FFI libs pact-reference/rust offers are around 7MB in size.
But moving to a dynamic lib for macOS would mean developers would also need to install rust on their machines? This could prove as a big barrier to adoption of PactSwift.

Reach out to me (@surpher) and we can talk about all of the approaches I've thought up. There's been quite a few, and a few approaches I've already tried I am really not proud of!

💬 Task Description

1. Remove support to run on physical devices.
2. Look for ways to not have to commit XCFrameworks and lib.as into repo

👩‍🔧 Technical Design Notes

🤝 Relationships

• Other Related Issues: surpher/PactSwift/issues/117

❕ Problem Statement

libpact_ffi.a files for all supported platforms are ridiculously large. LFS hosted on GitHub is out of the question for an OOS project. PactSwiftMockServer has already been set up to vend XCFramework package that strips down most of the unneeded runtime within the included libpact_ffi binaries.

Releasing a new version is tedious as it is currently done on a developer's machine and new XCFramework is pushed to the remote repository and tagged.

💬 Task Description

Create a GitHub action for release process that builds a new XCFramework, commits it into repository, tags the commit with version.

👩‍🔧 Technical Design Notes

• refactor build_xcframework script to automate on CI without user interaction
• put in failsafes (see previous point) avoiding unnecessarily blowing up the repo size
• use a pactSwiftMockServer.version file?
• check the version is bumped up compared to latest release version before continuing

🤝 Relationships

• ...

❕ Problem Statement

Whenever PactSwiftMockServer codebase changes a new XCFramework needs to be built to share the changes as a dependency.

💬 Task Description

• If applicable, pull libpact_mock_server_ffi and build the ffi binary for all supported architectures and move them in their respective sub-folders in /Resources
• Build archives of PactSwiftMockServer for each of the supported architectures
• Generate the new XCFramework
• Commit and upload to this repo
• Release a new version of PactMockServer
• Trigger a build in PactSwift

👩‍🔧 Technical Design Notes

• See ./Support/build_rust_dependency
• See ./Support/build_xcframework

🤝 Relationships

• Other Related Issues: #xxx, #yyy

❕ Problem Statement

When using PactSwiftMockServer it is difficult to know which libpact_mock_server_ffi version is wrapped.

💬 Task Description

Add the ffi_version key-value to the meta of generated Pact file.

👩‍🔧 Technical Design Notes

• `"libpact_mock_server_ffi": "0.0.16" (https://github.com/pact-foundation/pact-reference/releases/tag/libpact_mock_server_ffi-v0.0.16)

🤝 Relationships

• Other Related Issues: #xxx, #yyy

❕ Problem Statement

Currently, the exposed XCFramework supports the following architectures:

• x86_64-darwin
• arm64-darwin
• x86_64-ios (simulator)
• arm64-ios (physical device)

When using PactSwiftMockServer to run on an iOS Simulator running on arm64-darwin (Apple M1 chip), it might fail due to missing platform support.

💬 Task Description

• Build libpact_mock_server.a using aarch64-apple-ios-sim cargo triple.
• When creating XCFramework archive for -arch arm64 when archiving for simulator

👩‍🔧 Technical Design Notes

cargo +nightly build -Z build-std --target aarch64-apple-ios-sim

🤝 Relationships

• Depends on rust-lang/rust/issues/82412