The GitHub repository does not currently have ample automation for releasing .rbxm files. I’m looking into changing this in the future, but as of now, Wally will be the only way to install these modules.
And while I do believe in flexibility overall, that project value pertains to the modules themselves. Wally really is great, once you get started with it.
Modules should not […] force their depenencies on you
but also require users to use wally… Not everyone uses wally and so every new release should just have an rbxm file uploaded for each module. Automation isn’t required!
I was in the process of writing an actions workflow to release to both rbxm and Wally. Pesde too actually, before I discovered its architectural incompatibility with Wally. I unfortunately ran into issues when it came to rerunning steps for each of the modules. PRs welcome if anyone’s feeling generous.
Doing it manually adds friction to my development process. Many of the Moonlets modules are used across my own codebases. I give away the (free) code I feel comfortable with, and in exchange, I get to make my own impact and get a little bit of clout.
Obviously you’re not required to do it, and I’m not upset that you don’t because I can generate my own rbxm file if I download wally and rojo and all that – but it would take maybe 2 minutes to put an rbxm in the directory for each module, assuming you do it only when you update that specific module
- Types should be inferred where possible, giving you full typing on data you construct.
- You should not be locked into specific formats or methodologies. Not even OOP.
- Modules should not be bloated, overly-complex, or force their dependencies onto you.
