feat: Plugins improvements#410
Conversation
|
For some reason tests are failing in CI but not locally, debugging |
| } | ||
| } | ||
| ], | ||
| "networks": "./config/networks", |
There was a problem hiding this comment.
it is better to include the network that's being used, because otherwise you would need to include the networks folder in the example too.
There was a problem hiding this comment.
This is how is used in most examples and in out config.example.json
Co-authored-by: Luis Sebastian Urrutia Fuentes <luis@urrutia.me>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #410 +/- ##
=======================================
Coverage 92.6% 92.6%
=======================================
Files 214 216 +2
Lines 69159 70950 +1791
=======================================
+ Hits 64081 65749 +1668
- Misses 5078 5201 +123
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| "dependencies": { | ||
| "@openzeppelin/relayer-sdk": "^1.2.1", | ||
| "@types/node": "^24.0.3", | ||
| "ethers": "^6.14.3", |
There was a problem hiding this comment.
does test plugin need ethers or uuid?
There was a problem hiding this comment.
Good catch, leftover
| * Public interface for plugin API - only exposes methods that plugins should use. | ||
| * We are defining this interface here and in SDK. When changes are made to the interface, we need to update both places. | ||
| */ | ||
| export interface PluginAPI { |
There was a problem hiding this comment.
Cant we just import this type from the SDK?
There was a problem hiding this comment.
For backward compatibility for now
We can once we stop supporting runPlugin
3 participants
Summary
This PR introduces a new approach to creating plugins, aimed at decoupling plugin implementation from the relayer repository.
Previously, plugins had to be defined in the plugins directory and were required to import the runPlugin function and PluginAPI type from the relayer repository to function properly.
Now, the runPlugin function is no longer used, eliminating that dependency. Instead, plugins are exported as named handler functions, which our system automatically detects and invokes.
The PluginAPI type will be exported via the SDK package, allowing custom plugins to import it from there.
With the new approach, users can easily define their plugin logic in shareable third-party packages and use them directly in the relayer repository or through Docker.
Currently, both approaches are supported, but the runPlugin-based approach will eventually be deprecated.
NOTE: We should publish types via sdk and update dep version and examples before merging this one.
Testing Process
Checklist