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.

[ryanleecode]

I was thinking a helper function (my idea of load plugins) which is just import('@elizaos/plugin-coinbase').then((mod) => [mod.pluginA, modPluginB, modPluginC]). Then we don't need to import coinbase 3 times.

[ryanleecode]

And then to add them you can just spread:

plugins: [
...myCoinbasePluginsDynamicallyImportedOrNull
].filter(Boolean)

[ChristopherTrimboli]

ok this final point I think, taking break, will work on that, we getting close 👍🏻

[ChristopherTrimboli]

solved importCache I believe: 32c7e5a

Main issue was handling unique secrets, I do like the simple statements of secrets and importFn, now if duplicate importFn, it uses a cache, so won't import duplicates, but DX is much nicer else would have big nested ternaries and if/else stuffed in array with secrets spread.

If have better style lemme know.

[ChristopherTrimboli]

In case that secrets are exact same, uses your suggestion, as array to import: 430dab1

But case still stands I think best separated if secrets are unique, for webhook, and others.
https://github.com/elizaOS/eliza/pull/1383/files#diff-935219608f7b5ca6c8b8548cfdce88c7d3cdb6bb6d9f9d8df644b364f6557e4eR437-R462