feat: provide stable data exports for MMM-Remote-Control, mmpm, MMM-Config etc.

[KristjanESPERANTO]

Summary

Define a stable integration path for third-party tools (MMM-Remote-Control, mmpm, MMM-ModInstall and MMM-Config) as we move away from the wiki page and continue to evolve docs/data/modules.json. MMM-Config and MMM-ModInstall are already consuming modules.json, so any breaking change would currently break its integration.

Motivation

• Avoid regressions when the wiki list is deprecated/removed.
• Allow existing tools to benefit from the richer data we produce without having to scrape legacy formats.

Requirements & Ideas

• Catalog which fields each tool needs today (minimum viable contract).
• Consider publishing a schema (JSON Schema/OpenAPI) plus changelog so integrators can adapt proactively.
• Provide a communication plan for upcoming breaking changes (version headers, deprecation window, etc.).

[khassel]

MMM-Config already consumes modules.json, so any breaking change would currently break its integration.

well, you did already a breaking change about 2 weeks ago to modules.json which breaks my MMM-ModInstall module. You inserted modules on top level, I will fix it on my side.

For me the published modules.json is the new interface which will replace the wiki. So the main structure of this file should not changed anymore (maybe in this early stage changes are still possible but really ugly for the customers).

[sdetweil]

Yes. MMM-Config can adjust to a versioned url, if you tell me how I would know. I think this means reading a non-versioned url to get the versioned one, or its version identification to construct the url

[sdetweil]

Publish guides and sample parsers?
Do we NEED more consumers? To what end?

[KristjanESPERANTO]

you did already a breaking change about 2 weeks ago to modules.json which breaks my MMM-ModInstall module.

Oh, sorry about that. I hadn't thought of that 🙁

So the main structure of this file should not changed anymore

I also hardly think that we no longer need such a breaking change. In the unlikely event I would say we define the current state as API v1. If we make a major change, we'll introduce v2 in parallel without immediately shutting down v1. This would give API consumers time to migrate.

MMM-Config can adjust to a versioned url, if you tell me how I would know.

In the unlikely event that this occurs, I will write migration instructions.

Publish guides and sample parsers?

I now consider the idea to be exaggerated and have removed it from the issue text above.

Do we NEED more consumers? To what end?

We don't need any more consumers, but if we want to get rid of the wiki list, we should get projects like MMM-Remote-Control and mmpm (by the way, the two most popular modules (measured by GitHub stars)) ready for it.

[KristjanESPERANTO]

With release 3.3.0 of MMM-Remote-Control it doesn't rely any more on the wiki page 🚀

mmpm is still missing.

[khassel]

mmpm is still missing.

well, I tried it already but ...

We need to get rid of the wiki and therefore another new onboarding process ...

[KristjanESPERANTO]

I put a simpler approach for mmpm into a PR: Bee-Mar/mmpm#247

I also sketched out the target flow as I imagine it in a comment in that PR. Hmm... maybe the diagrams should be included in the project here instead 🤔

[sdetweil]

Like to see them, duh, click the link!