Move import/export logic into plugin

Hi everyone,

Thanks a lot for raising this issue and for suggesting this idea.

If anybody has some time, pointers, guidelines or suggestions on a possible implementation with plugins would be greatly appreciated.
For example, a basic module architecture with the necessary classes, plugins and perhaps examples of code that could be ported from the current implementation (eg. "this" would go "there").

We could find some time to work on this, but would appreciate at least some initial guidance so the time is spent more efficiently.

Thanks in advance.

I tried a couple of years ago to work on this issue, but I faced issues and erased my work.
I was too ambitious and was believing in a v3 of this module.

Today, I think the strength of this module is to be lightweight and precise. Of course, it should be flexible and evolve to make it better, but never trying to be the one solution fits all.

With this in mind, I would suggest splitting the work in those steps:
1. Defining what should be common for any entity type handled by this module
2. Creating the plugin manager system and refactoring the current mechanism without creating BC breaks

And good to have would be
3. Add tests about adding a dummy entity type handling
4. Add documentation for how to extend this module with a custom Plugin/EntityType

About point 1. I would say we can make generic
- the export method
- the 3 types of imports (safe, full, force) at least as a first step (maybe later let Plugins implement any type of import)

But already facing an issue, the config schema is not extendable. I mean, there is only one structure_sync.schema.yml for all types.
As a first step, we could let plugins write to a different config with defining their own config schema
But later we should target this other important issue https://www.drupal.org/project/structure_sync/issues/3012034 📌 Split structure_sync.data.yml to reduce risk of conflicts Active , sadly hard to make it work without BC breaks.

Please feel free to challenge this vision and debate

Just wanted to document here a useful example of a plugin system implementation, which doesn't seem "too" complicated, see module: Queue UI → , in particular the way it defines a backend queue_ui plugin:
https://git.drupalcode.org/project/queue_ui/-/blob/3.1.x/src/Annotation/...