discussion: plugin interface definition

[Quantumlyy]

May I inquire on how plugins will work so that api can be redesigned to fit it. Would it still be all at the end of the constructor or could it also be at the start so that internal structures could be modified before their use?

[kyranet]

I was thinking of setting up a standard where my-plugin-name/register sets up module augmentation and extends the client, whereas my-plugin-name just exports the types and the classes, so users can set them under any export.

What are the API changes you want for the plugin support and how do you want it to be done?

[Quantumlyy]

Is this similar to how you have to call import "module-alias/register"?

One of the issues faced in Klasa was that you couldn't overwrite base piece structures since the plugin would be loaded after their initial use which required the points plugin to extend Command instead of "extending" it and adding a new base property. I believe this follows the concept of d.js extensions in a usage sense.

I've seen that sapphire now sports hooks as well and they seem good to offload some of the work of plugins. So possibly allow plugins to setup default hook methods?

And finally, a concept we discovered when discussing plugins for Axon, a lifecycle system akin to hooks to allow plugins to be loaded at different stages of the startup/load procedure.

I apologize if any of my points seem incoherent or colliding. I figured I'd propose some ideas while the project is still young.

[kyranet]

I'm open to any suggestions, although I'd appreciate if we can get typed definitions/schemas alongside a brief description if something is not exactly clear, this way we can evaluate how feasible features are.

Is this similar to how you have to call import "module-alias/register"?

That's a possibility. They can call Client.use internally (or whichever method we decide), and seems to play well with your Axon plugins as plugin developers can specify said lifecycles.

I've seen that sapphire now sports hooks as well and they seem good to offload some of the work of plugins. So possibly allow plugins to setup default hook methods?

Sure, I have been considering adding some properties to set-up each store's hooks (and even override them) via SapphireClientOptions, although the docs might have a notice regarding them being advanced features.

And finally, a concept we discovered when discussing plugins for Axon, a lifecycle system akin to hooks to allow plugins to be loaded at different stages of the startup/load procedure.

I'm not familiar with Axon, nor plugins loaded this way, you might need to elaborate more.

[Quantumlyy]

I'm not familiar with Axon, nor plugins loaded this way, you might need to elaborate more.

It plays into my original suggestion of loading plugins at different points, like at the start of the constructor, at the end of the contractor, start or end of the login method... and so forth. This was the reference I mentioned. A plugin gets loaded at the start and end of the constructor. The plan was to add more points but never carried on as Pengu dropped Axon.