How to handle one mono flutter repo on a multi dll rust plugin system.

[Vluurie]

Hey everyone,

We've been using a plugin architecture where each "mod" is its own dynamic-link library (DLL). Historically, each plugin had its own dedicated Flutter project, and we used flutter_rust_bridge (FRB) to handle the bindings. This setup worked, with each DLL's bindings and hash matching correctly. However, we've noticed several significant issues with this approach:

Duplicated Logic: We're seeing a lot of redundant code across different plugins.

Slow Compilation: Compiling each separate Flutter project is time-consuming.

Large DLLs: Each plugin's DLL is bloated because the Flutter project is included as an embedded binary, leading to larger file sizes.

Our current process, where a modloader (loaded into the game executable) checks for and extracts the Flutter project from a plugin DLL, is complex, full of boilerplate, and slow. This is compounded by our custom flutter rust embedder setup that loads each Flutter overlay into the same process as overlays onto of overlays. This would also eliminate complexity as only a single overlay would need to be loaded instead of many that each makes there own GPU context.

Proposed Solution & The Core Challenge

To address these issues, we're considering a new approach: a single monorepo for all Flutter UI code. This mono repo would contain the logic for all plugins. The goal is to generate bindings for all plugins from this central location, eliminating the need for each plugin to have its own Flutter project.

The central problem I'm trying to solve is: How can we generate FRB bindings for our plugins without making the plugins direct dependencies of the main flutter_ui.dll?

Currently, I've tried adding plugin_1::api and plugin_2::api as dependencies via the rust_input configuration (crate::api, plugin_1::api, plugin_2::ui::api). While this correctly generates all the bindings, it causes a compilation problem: each plugin's init logic gets compiled into the flutter_ui.dll because they are dependencies. This is not the desired behavior, as the plugins should remain separate DLLs that get loaded dynamically.

I'm struggling to figure out a way for FRB to generate the bindings while the plugins themselves are not compiled into the main flutter_ui.dll.

My proposed idea is to use ExternalLibrary.process() within the Flutter overlay. The modloader would inform the Flutter UI about which plugins have been loaded, and the UI would then find and use their functionality within the same process. This would work if the bindings can be generated without a direct compilation dependency.

Any thoughts on how to achieve this with FRB or a similar approach? I had in mid if this is not possible with FRB, that we will switch to native sendport and method channels, but this leads to alot of extra work where we thought that FRB would be perfect for this.