Here is the current list of proposed changes to the Pact Plugin architecture. Proposals 004–009 are listed in delivery order rather than numerical order.
| Proposal | Phase | State | Discussion |
|---|---|---|---|
| V2 Plugin Interface | Historical | Superseded | #83 |
| Support script language plugins | Phase 2 | Implemented | #84 |
| Support WASM plugins | Background | Draft | #85 |
| Support Python as a second script language plugin | Phase 2 | Draft | |
| Verification contract cleanup | Phase 1 | Implemented | |
| Plugin capability negotiation and versioning | Phase 1 | Implemented | |
| Plugin observability and logging | Phase 2 | Implemented | |
| Field-level matchers and generators | Phase 3 | Implemented | |
| Driver-plugin callback model | Phase 3 | In progress | |
| Host-provided core matching and generation | Phase 4 | In progress |
Phase 1 — Foundational (004, 005) These two proposals are independent of each other and establish the groundwork for all later work. 004 cleans up the verification contract so plugins no longer need to parse full Pact JSON. 005 introduces explicit capability negotiation so new interface features can be adopted incrementally without an all-or-nothing version bump. Both must ship before any Phase 2 or later work begins.
005's negotiation mechanism is implemented and everything downstream builds on it, and its Phase 1 capability set - one capability per interaction type a Pact file can record - is now wired up in both directions: both hosts register the three interaction types as core catalogue entries and advertise them, and both drivers check a plugin's declared interaction capabilities before handing it an interaction to verify.
Phase 2 — Observability (008) 008 addresses a real and immediate user pain point — plugin logging is currently difficult to work with. It is largely independent of the new functionality proposals and should be delivered after Phase 1 but before the more complex Phase 3 work, so that diagnostic improvements are in place before the interface grows more complex.
Phase 3 — New functionality (006, 007) 006 and 007 can be designed in parallel. 007 (the callback model) must define its logical interface first; the concrete gRPC and WASM transport mappings follow from that definition. 006 (field-level matchers and generators) aligns with 007's data model but does not depend on it being fully implemented first. 006 is implemented; 007 is implemented apart from its WASM transport, which is blocked on 003 (006 leaves its own WASM mapping to that point by design).
Phase 4 — Host-provided matching (009) 009 depends on 005, 006, and 007 all being finalised; all three are now implemented. Both hosts register the standard matching rules and generators as core catalogue entries with handlers behind them, at content and field level, so a plugin can delegate a standard rule or generator to the host it is running under. What remains is the WASM transport, which is blocked on 003.
Proposal 003 (WASM-based plugins) is in scope alongside the V2 interface work. Proposal 002 (script language plugins) is not being pursued.
All proposals in this set must treat the interface as a transport-neutral logical contract. Every design decision should be validated against both runtime models:
- gRPC plugins run as external processes and communicate over a network connection; new operations become new RPCs.
- WASM plugins run in-process; new operations become exported or imported WASM functions or host function calls.
Concrete examples in the proposals may use gRPC for illustration, but the logical interface must not embed transport-specific assumptions.