Coming back to the Pact Plugin proposals. There ha...
# maintainers
r
Coming back to the Pact Plugin proposals. There has been no work on this since 2024, because busy. I have got Mr Claude to revise the proposals and we have broken them down into a number of smaller ones and also fixed a lot of things that were just confusing or no longer relevant. Docos are here: https://github.com/pact-foundation/pact-plugins/blob/main/docs/proposals/README.md
👀 2
❤️ 1
m
So my recollection is that the WASM based plugins had poor support in JVM, which effectively meant it wasn’t feasible to use. Has this situation changed? (I don’t see updates in https://github.com/pact-foundation/pact-plugins/blob/main/docs/proposals/003_Support_WASM_plugins.md)
(I take the point about phase 1 and 2, however, which are independent)
r
I haven't looked at WASM, apart from making the other proposals take a potential WASM interface into account. I.e. don't build gRPC specific things in
👍 1
Concrete examples in the proposals may use gRPC for illustration, but the logical interface must not embed transport-specific assumptions
👍 1
t
I vibe-coded 2 rust-written plugins: • https://github.com/tienvx/pact-sse-plugin • https://github.com/tienvx/pact-sync-message-test-plugin I tested them and they work fine for me. I've never seen the code since then. Because I'm lazy, the rust code is hard, I don't have time ... With that in mind, I have some questions, which may help improve the pact plugin system, or not, depend on these questions are valid or not in the first place: • As I understand, each plugin need to belong to (or related to) a content type (e.g.
text/event-stream
), or define a fiction content type (e.g.
application/test
). Can the plugin independent from the content type? maybe related to 006 • Can I define new "standalone" matching rules and generators using plugin? They are not defined in v4 specification, and work with any content types (json, xml, ...), not just the content type the plugin belong to (see the question above). Maybe related to 006 and 009. Btw, I create an rfc for a new 'random array' generator, but no feedback so far (maybe because it's not listed in pulls?), I would love to have ability to create the plugin just for that generator. • Can we define multiple plugins per interaction? Can we define multiple plugins per integration (each consumer-provider pair)? Look at the pact json structure, maybe the answer is yes for both? I didn't test this kind of behavior before. If the answer is no, I would love this feature, because of the previous question. If I have many standalone matching rules and generators, I would like to use many of them in single interaction.
cool doge flip 1
m
facepalm oh, github
r
As I understand, each plugin need to belong to (or related to) a content type (e.g.
text/event-stream
), or define a fiction content type (e.g.
application/test
). Can the plugin independent from the content type?
The design defines different types of plugins. There are plugins that deal with certain types of content (content plugins, and yes, those are related to a content type) and transport plugins (implementing a transport protocol, these may be associated with some type of content, for instance, gRPC requires Protobufs), but there are other types as well that are not associated with any type of content. We haven't created any of these yet.
fb wow 1
Can I define new "standalone" matching rules and generators using plugin? They are not defined in v4 specification, and work with any content types (json, xml, ...), not just the content type the plugin belong to (see the question above). Maybe related to 006 and 009. Btw, I create an rfc for a new 'random array' generator, but no feedback so far (maybe because it's not listed in pulls?), I would love to have ability to create the plugin just for that generator.
This is in the design, but there is no support implemented for these types of plugins yet.
Can we define multiple plugins per interaction? Can we define multiple plugins per integration (each consumer-provider pair)? Look at the pact json structure, maybe the answer is yes for both? I didn't test this kind of behavior before. If the answer is no, I would love this feature, because of the previous question. If I have many standalone matching rules and generators, I would like to use many of them in single interaction.
Yes, the design and implementation allows for multiple plugins
💯 1