Working plugin architecture with cargo watch and workspaces?

[benmp]

Hello,

I am trying to figure out the best way to develop an application that uses dylibs as plugins. Here is my folder structure:

my_app/
  Cargo.toml
  src/
    main.rs
    shared_lib.rs
  plugins/
    Cargo.toml
    test1/
      src/
        lib.rs
    test2/
      src/
        lib.rs

my_app's Cargo.toml is just a normal bin.
plugins' Cargo.toml is a workspace project, with members of test1 and test2

So far this works well. I load plugins using libloading inside of main.rs.

The issue I now have is with development workflow.

Currently test1 and test2 do not depend on eachother (I'm not sure how practical this is, but it's currently my plan to have all plugins be standalone from eachother). If I make a change in test1, I have to cd to that directory and manually run cargo build before my_app detects the change in a plugin file, and hot reloads it. I plan on having dozens of plugins.

1. Is there any good way (besides creating a shell for each plugin with its own watch task), to have a watch task run on plugins/ and only recompile individually changed libraries?

2. I am not yet using shared_lib.rs in any of my plugins/, but I intend to share types and traits through that file. Does the above nested workspace folder setup lend well to that idea, or am I going about this all wrong?

Thanks!

[benmp]

Whether or not the above is the correct approach, it does appear to be working as I had hoped so far using cargo watch -s "cargo build --all" inside the root plugins/ folder