Automatic checking of all MagicMirror² modules

BKeyport

@mumblebaj Old page may be outdated, but at least it’s sorted much better, and compact. New and flashy does not make a successful page sometimes.

We need to keep the compactness of the old way, somehow, and not bury good modules under bad ones - this is the main problem I see with this site.

I can’t hit my browser’s text search and look for calendar for example. I get MMM-CX2 and MMM-CX before I even come close to the current MMM-CX3, and totally miss my mini calendar module.

mumblebaj

@BKeyport As an IT person I would say we need to move with the times. Being stuck in the old is never good. Have you tagged your modules as per the stats gathered on it?

BKeyport

@mumblebaj 90% of the modules in the system are outdated and would never be tagged, so…

mumblebaj

@BKeyport Gives users an indication that they are outdated and may not be supported. My point is being stuck in the past is never a good idea unless you want your project to “die”

sdetweil

@mumblebaj lots of useful modules haven’t been updated. pages for example…

so old is not bad necessarily

MMRIZE

I don’t care if it is not updated or not as long as it works.
However, we can call some unmaintained-anymore modules legacy. Maybe a tag legacy to some old modules be a good way to distinguish. By contrast, the other side might be modern.

If possible, I wish for more features/rules for common "modern" modules. These could help automate the management of modules.

Installer command/script/instruction
Some modules may need additional manual pre-requisition or dependency jobs (e.g. getting auth), but most of the modules would be possible to prepare simple scripts for installation. (in package.json and specific installer folder). If so, we can provide an auto-install/update feature to MM.
Basic default configuration example file.
If possible, a default config example would be a help for the newbie, and with that content, auto-configuration would be possible in the installation stage.
Of course, there might be private-information or API-Key issues…
Using .env to store private/secure information. (Or private.json something…)
To separate normal configuration from sophisticated private data (e.g., API Key, Account, password, etc.) , using .env may be the option. It could be composed through an installation script if needed.

I wish we could have something like a plugins market or bundle store of other applications.

BKeyport

@MMRIZE I’d love to see a plugin store and/or marketplace of sorts. Some other projects uses NPM with a fancy front end web to do so, much like some modules use(d) a web interface to set up the initial config or adjust configs (Sam’s config module, MMM-RTSP, etc)

This would be an ideal marketplace (Simple, to the point, shows everything a user needs) :

Then when the user wants to config:

Homebridge is one of the better ways of doing things, IMO.

BKeyport

By the way, the verify system for them is to verify the module is stable, etc, once you get verified, you can advertise for donations within the system, this is why I have a red heart on mine. (all of my modules/plugins/etc I do I have a donation link for a charity I like)

BerkSmash1984

@KristjanESPERANTO is the third-party modules site having issues? Currently seeing this:

sdetweil

@BerkSmash1984 seems OK