-
Notifications
You must be signed in to change notification settings - Fork 137
Plugins Implementation #1794
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Plugins Implementation #1794
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, this design makes sense to me.
| // Process plugins first to allow them to modify connect configuration | ||
| for (const plugin of options?.plugins ?? []) { | ||
| if (plugin.configureClient !== undefined) { | ||
| options = plugin.configureClient(options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we ever expect/support a plugin altering the plugin list?
I'm not sure I can think of a reason for doing this, but the current implementation would allow altering the list, but the iteration wouldn't change. e.g. a removed plugin can still alter the options/added plugin will not get a chance to alter the options
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't intend to support that. If you have an idea of how to enforce that, we could.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could leverage Omit to make it clear that plugins won't be respected e.g. configureClient?(options: ClientOptions): Omit<ClientOptions, 'plugins'>
Running the configurations becomes a little more awkward as you have to destructure options each iteration e.g.
// Add client plugins from the connection
options.plugins = (options.plugins ?? []).concat(options.connection?.plugins ?? []);
let { plugins, ...optionsWithoutPlugins } = options;
// Process plugins first to allow them to modify connect configuration
for (const plugin of options.plugins) {
if (plugin.configureClient !== undefined) {
optionsWithoutPlugins = plugin.configureClient({...optionsWithoutPlugins, plugins });
}
}
options = { ...optionsWithoutPlugins, plugins };
super(options);
It doesn't warn/error if the user tries to alter the plugin list, but any changes they make won't be respected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Omit is a good idea. It seems like I can just change the type in the plugin to Omit<ClientOptions, "plugins"> without any other change. They can return something with changed plugins, but expresses the intent
What was changed
Add plugin types for Connection, NativeConnection, Worker, Client, and Bundler, as well as a SimplePlugin class for easy construction of new plugins.
Why?
Plugins make it easier to share common configurations and apply them consistently.
Checklist
Closes [Feature Request] Plugin support #1764
How was this tested: