Module already written - how do I request a repo without Slack?

[Utopian-Academy]

I have written a Companion module for Deckboy, an open-source cue-based playback and show-control application for live video (GPL-3.0, Windows / macOS / Linux). I would like to get it into the module list, and I am stuck on the first step.

The module is finished and passes the official tooling:

• companion-module-check passes — validateManifest is clean
• companion-module-build packages without errors against @companion-module/base 1.14.1
• it polls STATUS and exposes feedbacks for tally, transport state, output health and a cue countdown, so a key knows whether the cue it fired actually went live
• npm test covers the status parser against a captured reply from the application

Source, as a subdirectory of the main repo for now:
https://github.com/Utopian-Academy/Deckboy/tree/main/companion-module-utopianacademy-deckboy

The releasing-your-module docs say to request a repository in #module-development on Slack. I do not use Slack and would rather not open an account purely for this. Is there another route to request the repo — here, by email, or somewhere else — or is Slack genuinely the only way in?

Happy to move this to a different category if Q&A is the wrong place for it.

[thedist]

Slack is the only place we currently support for repo requests as that's how we manage the queue, it's also where we provide module developer support, we often reach out to developers through Slack, key updates/breaking changes are also brought up there etc...

Also as a side note, modules MUST follow the companion-module-MANUFACTURER-PRODUCT naming scheme, so that would need to be sorted before your module would even be eligible anyway.

[Utopian-Academy]

Thanks — both points taken, and the naming one was a fair catch.

Renamed. It is now companion-module-utopianacademy-deckboy, with id and name both utopianacademy-deckboy and shortname Deckboy, following the one-squashed-lowercase-token convention I can see in your org (lacoustics, audiotechnica, renewedvision). Manifest validates and the tests pass under the new name.

Slack. Understood that it is the only route — I have joined and posted the repo request in #module-development.

One question while I am here, because it decides whether there is real work to do before review: the module currently targets @companion-module/base ^1.12.0 with runtime.type node18. I can see other requests in that channel citing 2.1.x and node22 for Companion 5. Is 2.x required for a new module to be accepted now? If so I will do the migration before taking up any reviewer time — it is a genuine breaking-change pass for us (runEntrypoint to a default export, setVariableDefinitions array to object, the tcp/udp helper rework, and parseVariablesInString being removed, which we use in fourteen places), not a version-string edit.

For anyone who finds this thread meanwhile: the module is usable today without waiting on any of the above. Every Deckboy release ships Deckboy-companion-module-<version>.zip containing the module and its dependencies — unzip it, point Companion's developer modules path at the folder containing it, restart, and it appears in the connection list. Deckboy itself is GPL-3.0 and free, for Windows, macOS and Linux: https://github.com/Utopian-Academy/Deckboy

[thedist]

Using the latest module base version is not required to pass review, and what base version does limit what versions of Companion your module will run on, for example base 2.0.x requires Companion v4.3 or higher, where as base 2.1.x requires Companion v5 or higher (full compatibility list can be found here: https://github.com/bitfocus/companion-module-base/tree/main/packages/base#supported-versions-of-this-library)

That being said though, there are some features in the newer versions that are very powerful (for example being able to use expressions in action/feedback options, better ways of handling presets, etc...) so some users will see it as a negative that your module doesn't provide them the same capabilities that a growing number of other modules provide. There may also be a point in the future where Companion itself stops supporting legacy versions of the module base, potentially blocking the module being installed and run, but that's not something that's on the near-term roadmap.