I have been going around in circles thinking about...
# maintainers
r
I have been going around in circles thinking about how to support simpler Pact plugins, especially when we want to have plugins that can provide new matchers and/or generators. I have come back to using scripting languages as a good candidate for that. I did a spike a few years ago with a Lua content type plugin supporting JWT and that seemed to work ok but only with Rust. A brief investigation for JVM support, and I think it is doable for both Lua and Python. Javascript is a bit more of a problem, firstly they have dropped the Nashorn engine from the JVM in JDK 15, but it is a separate project now so we could still use it. Also, it will be supporting pure JavaScript not Node, and will require something like Webpack to bundle the plugin code.
👀 1
I think starting with Lua and get it working on both the Rust and JVM drivers with LuaRocks package support (pure Lua only) is the first step. Then add support for Python. I am unsure how the Python packages and virtual environments would work in a Plugin ecosystem, but I'm expecting it to not be too difficult. The issue is more my knowledge than the language ecosystem.
👍 1
JavaScript would then look like Nashorn engine on the JVM and possibly Mozilla SpiderMonkey engine with Rust (I would like to avoid the V8 build system which is based on Google C++ tools). But we would need to create host functionality to support things like file system access.
I also think it fine to not support JavaScript, just to be mean to all the script kiddies
😆 1
PR for Lua plugins. Supports both the Rust and JVM implementations. Includes a JWT plugin written in Lua and an example project that uses it. github.com/pact-foundation/pact-plugins/pull/104
👀 1
m
One thing I’ll say is that we did get a lot of feedback of “why Lua” with the Drift launch, and pretty much everyone asked if we could support JS. I think we can justify it, but we should maybe try a few to see how they work out before releasing it into the wild. I agree that the need to access libraries/packages is likely to make-or-break things. In all but the simplest of cases, you’re going to need to reach out to other packages (e.g. for networking, crypto etc.) and that’s where the DX could get messy - especially x-system
This is where Python/Node would be better, because the ecosystem has good support for the API universe (I don’t know how popular Lua is as a backend language, is what I’m saying, and it stands to reason the kinds of libraries you might need to handle different API technologies may not exist or be immature)
r
People can use gRPC-based node plugins if they can only see JavaScript code
m
right, that’s true