chore: dynamic plugin imports

[ChristopherTrimboli]

Relates to:

None, just looking for improvements.

Risks

HIGH - could break plugins

Background

Plugins even if unused are being always imported into the agent/index.ts at top of file.
This adds much memory usage to the JS runtime and not most efficient way to load optional plugins.

What does this PR do?

Dynamically imports plugins when needed based on ENV / secrets loaded.

What kind of change is this?

Improvements (misc. changes to existing features)

Why are we doing this? Any context or related work?

Makes Eliza faster / slimmer / less bloated / scales infinite plugins with minimal runtime overhead.

Documentation changes needed?

My changes do not require a change to the project documentation.

Testing

Try out different combinations of plugins off and on, see if loads or breaks.

Discord username

cjft

[ChristopherTrimboli]

P.S. - seems like passed all tests, omg, nice... just noticed could do same for all client packages: if we like this change, ill do another PR for dynamic client imports too, massive optz.

[ChristopherTrimboli]

hmmm avaer told me that "alot of wrappings" I can make better abstraction for loading dynamic imports... I'll work on. Like a function for it instead. Bit complex because of all the diff conditionals / import styles / 1 is a default import. I'll see if can do nicely.

[ChristopherTrimboli]

hmmm avaer told me that "alot of wrappings" I can make better abstraction for loading dynamic imports... I'll work on. Like a function for it instead. Bit complex because of all the diff conditionals / import styles / 1 is a default import. I'll see if can do nicely.

done, now have loadPlugin() abstraction with very simple string based plugin config.

[ryanleecode]

Why do it like this? Why not pass a callback to loadPlugin that is async () => import('my plugin')

[ryanleecode]

The probably is the public api is purely string base its not type safe where as if you do callback import and you don't have the dependency installed, typescript will not compile it.

[odilitime]

Probably need to update

eliza/scripts/dev.sh

Line 45 in 4c658d7

* 5. Edit the 'index.ts' file in 'agent/src': *

for future plugin devs

[ChristopherTrimboli]

Why do it like this? Why not pass a callback to loadPlugin that is async () => import('my plugin')

OK yeah callback param is better, I'll update.

[ChristopherTrimboli]

changed to callback params: 2efee64

[ChristopherTrimboli]

Probably need to update

eliza/scripts/dev.sh

Line 45 in 4c658d7

* 5. Edit the 'index.ts' file in 'agent/src': *

for future plugin devs

c5d4dc4 updated plugin instructions

[ryanleecode]

This doesn't work your loadPlugin returns null but the function is typed as Promise<any> where as the constructor parameter only takes Plugin[]. Giving it a null plugin will definately fail.

IMO the correct approach would be something as follows.

1. Create a dynamic Plugin type such as

export type DynamicPlugin = {
    readonly factory: () => Promise<Plugin>;
    readonly shouldInit: (character: Character) => boolean;
};

2. Make the AgenRuntime constructor private and create a static factory function that is async and accepts ReadonlyArray<Plugin | DynamicPlugin> as a parameter. Await the dynamic parameters in the async static factory. Bonus points for adding _tag: 'Plugin' and _tag: 'DynamicPlugin to the respective types, although this would be a high impact change since it would fuck over downstream plugins.

[ChristopherTrimboli]

This doesn't work your loadPlugin returns null but the function is typed as Promise<any> where as the constructor parameter only takes Plugin[]. Giving it a null plugin will definately fail.

IMO the correct approach would be something as follows.

1. Create a dynamic Plugin type such as

export type DynamicPlugin = {
    readonly factory: () => Promise<Plugin>;
    readonly shouldInit: (character: Character) => boolean;
};

2. Make the AgenRuntime constructor private and create a static factory function that is async and accepts ReadonlyArray<Plugin | DynamicPlugin> as a parameter. Await the dynamic parameters in the async static factory. Bonus points for adding _tag: 'Plugin' and _tag: 'DynamicPlugin to the respective types, although this would be a high impact change since it would fuck over downstream plugins.

I see, more complex with types then I originally thought, will think about / work on, thanks for feedback.

[ryanleecode]

This doesn't work your loadPlugin returns null but the function is typed as Promise<any> where as the constructor parameter only takes Plugin[]. Giving it a null plugin will definately fail.
IMO the correct approach would be something as follows.

1. Create a dynamic Plugin type such as

export type DynamicPlugin = {
    readonly factory: () => Promise<Plugin>;
    readonly shouldInit: (character: Character) => boolean;
};

2. Make the AgenRuntime constructor private and create a static factory function that is async and accepts ReadonlyArray<Plugin | DynamicPlugin> as a parameter. Await the dynamic parameters in the async static factory. Bonus points for adding _tag: 'Plugin' and _tag: 'DynamicPlugin to the respective types, although this would be a high impact change since it would fuck over downstream plugins.

I see, more complex with types then I originally thought, will think about / work on, thanks for feedback.

Actually I stand mistaken since there is a filter(Boolean) and the end the nulls get filtered out. So this would work but I don't think we need the third parameter b/c u can do import("whatever").then((mod) => mod.myPlugin) which is also type safe.

[ryanleecode]

Few more comments.

1. probably export the loadPlugin function
2. create another function loadPlugins, and then i can just spread the resulting array

[ChristopherTrimboli]

OK strictly type loadPlugins with Plugin + mod style, this works and is type compliant however we now have 3 plugins not correctly typed to Plugin that were hidden found:

@elizaos/plugin-solana
@elizaos/plugin-near
@elizaos/plugin-goat

This is bigger PR to fix all plugins now, was never type safe to begin with tbh.

[ryanleecode]

Have you run pnpm build in the root of the monorepo?

[ChristopherTrimboli]

Have you run pnpm build in the root of the monorepo?

ah, fixed, OK everything compiling / working great. Gonna work on:

1.) export the loadPlugin function
2.) create another function loadPlugins, and then i can just spread the resulting array

to cleanup and ready for review / testing. thanks for help! TS god

[ChristopherTrimboli]

I went big boy AAA on this one:

23cb080

I think this proper now. ready for review kind citizen.

[0xCardinalError]

Nice PR. On the topic of plugins, I am thinking about what would be good solution in long term for plugins, as there will be hundreds of them. It makes no sense to import them all or even have them in code. I like the approach of just adding them in .json file for each character. So maybe we can have some core plugins and just contrib plugins where it can be whatever.

[odilitime]

If I fix the conflicts is this ready to merge?

[ChristopherTrimboli]

If I fix the conflicts is this ready to merge?

I fixed conflicts and added more new plugins back. Should be good for testing in dev, I didn't get chance to try every plugin, this high risk. I think it's ready for merge myself.

[ChristopherTrimboli]

Nice PR. On the topic of plugins, I am thinking about what would be good solution in long term for plugins, as there will be hundreds of them. It makes no sense to import them all or even have them in code. I like the approach of just adding them in .json file for each character. So maybe we can have some core plugins and just contrib plugins where it can be whatever.

true some theory crafting there, but issue is types need to be correct in build, I originally made some string solution but does not validate Plugin type in TS properly, ryanleecode roasted me, I think .json for plugins may not workout.

[0xCardinalError]

Nice PR. On the topic of plugins, I am thinking about what would be good solution in long term for plugins, as there will be hundreds of them. It makes no sense to import them all or even have them in code. I like the approach of just adding them in .json file for each character. So maybe we can have some core plugins and just contrib plugins where it can be whatever.

true some theory crafting there, but issue is types need to be correct in build, I originally made some string solution but does not validate Plugin type in TS properly, ryanleecode roasted me, I think .json for plugins may not workout.

I found it perfectly suitable that char is build with .json and then we just add something like

    "plugins": [
        "@elizaos/plugin-dexscreener", ""@elizaos/plugin-geckio","
    ],
    ```
    
    to it and list plugins we want to load besides "core" ones. 

[ChristopherTrimboli]

Nice PR. On the topic of plugins, I am thinking about what would be good solution in long term for plugins, as there will be hundreds of them. It makes no sense to import them all or even have them in code. I like the approach of just adding them in .json file for each character. So maybe we can have some core plugins and just contrib plugins where it can be whatever.

true some theory crafting there, but issue is types need to be correct in build, I originally made some string solution but does not validate Plugin type in TS properly, ryanleecode roasted me, I think .json for plugins may not workout.

I found it perfectly suitable that char is build with .json and then we just add something like

    "plugins": [
        "@elizaos/plugin-dexscreener", ""@elizaos/plugin-geckio","
    ],
    ```
    
    to it and list plugins we want to load besides "core" ones. 

got clarification, forgot Eliza is multi-agent support, understood, will handle the plugin in .json and active for all loaded characters in dynamic import style, not too bad update, coming soon.

[ChristopherTrimboli]

ready for review, let's stick to just the top of file imports being removed, not overcomplicate this, 1 for 1 these changes are an improvment, nothing different logically, plugins in character configs still do their thing.