Automatic checking of all MagicMirror² modules

BKeyport

@sdetweil We already have some standards in place (node_helper.js, naming conventions, package.json, etc) - what’s one more (config-schema.json) for the programmer? Think along the lines of the schema.json file used in MMM-Config.

Programmer creates the GUI settings page, using API into a specific file. It’s up to the core to insert result into the main config file. if GUI file isn’t there, then resort to a web based editor.

https://github.com/homebridge/homebridge/wiki/Verified-Plugins describes the process in homebridge’s case. Provide a reward, and bam - We’ve got easier access to the project, making it more widespread, and it completely eclipses the automatic checking process here.

Reward for the programmer is rather simple. A badge set thusly - everywhere - in the built in plugin manager’s search, on websites, etc.

Example - No GUI settings page file (the dead module):

Example - GUI settings page file (my reworked module with more functionality):

and the resulting config (I believe they use JSON rather than JS):

sdetweil

@BKeyport I believe we use js because you can have comments, json does not support comments

BKeyport

@sdetweil It don’t matter how it’s done, honestly. JS, JSON - Same diff in my book… I’d just love to see it get simpler, and wrap up some of these projects into one.

sdetweil

@BKeyport what we really need is an AI page layout/designer tool. mushing all these disparate css together w the base design is getting beyond most people’s capabilities. I know it’s way beyond mine.

KristjanESPERANTO

Meanwhile, there have been some changes to the module list. E.g.

If you click on a maintainer’s name, you will get a list of all modules by that maintainer :smiley:
Dark mode switch
Style changes
Many module maintainers added screenshots and keywords and fixed listed issues
GitHub stars are displayed
New sort option: number of stars
Module tags are now clickable
Screenshots are now clickable
Optimized mobile view

And some more …

Jalibu

@KristjanESPERANTO are there plans to make this the official linked modules store on the project‘s page?
In my opinion it is already by far better than the existing one. I‘d also vote for making this the source of truth without dependency to the old page as a datasource

KristjanESPERANTO

@Jalibu wrote:

are there plans to make this the official linked modules store on the project‘s page?

I’m definitely open to the idea of turning it into an official part of the project and moving it to MagicMirrorOrg, for example.

However, I have not yet sought dialogue with the core developers in this regard. It would be very interesting to hear if the core developers are open to that idea. @karsten13 , @rejas and @sdetweil, what do you think?

I‘d also vote for making this the source of truth without dependency to the old page as a datasource

The current solution (the list in the wiki) works and does not cause any additional work for the core developers.

However, as soon as we automate the process of creating the new module webpage, a vandal could provoke ugly effects. That’s why a different approach to maintaining the list, one that provides more protection against (intentional and unintentional) vandalism and includes a simple quality check, would make sense.

My concrete suggestion would be to create a pull request template for this purpose.

If we decide that “my” list should become an official part of the MM project, I would spontaneously suggest these rough milestones in the following order:

moving the repository to MagicMirrorOrg.
finding a better way to maintain the source of truth (currently the wiki page).
replacing/redirect references to the old module list.
automating the creation of the module list website.

karsten13

@KristjanESPERANTO said in Automatic checking of all MagicMirror² modules:

@Jalibu wrote:

are there plans to make this the official linked modules store on the project‘s page?

I’m definitely open to the idea of turning it into an official part of the project and moving it to MagicMirrorOrg, for example.

However, I have not yet sought dialogue with the core developers in this regard. It it would be very interesting to hear if the core developers are open to that idea. @karsten13 , @rejas and @sdetweil, what do you think?

I‘d also vote for making this the source of truth without dependency to the old page as a datasource

The current solution (the list in the wiki) works and does not cause any additional work for the core developers.

However, as soon as we automate the process of creating the new module webpage, a vandal could provoke ugly effects. That’s why a different approach to maintaining the list, one that provides more protection against (intentional and unintentional) vandalism and includes a simple quality check, would make sense.

My concrete suggestion would be to create a pull request template for this purpose.

If we decide that “my” list should become an official part of the MM project, I would spontaneously suggest these rough milestones in the following order:

moving the repository to MagicMirrorOrg.

finding a better way to maintain the source of truth (currently the wiki page).

replacing/redirect references to the old module list.

automating the creation of the module list website.

I’m fine with this. The Wiki stuff should not stay the source of truth, this construction is horrible. Maybe we have to wait until we have full control over MagicMirrorOrg …

sdetweil

@KristjanESPERANTO @karsten13

I’m also ok with this style list becoming the current. but I think the order of task needs to change

show how to resolve the integrity problem, without constant intervention
show the automation
then move to org
then redirect links, and seo
and
show how we migrate the list as new requirements come along. is it you that becomes the maintainer?

mumblebaj

@KristjanESPERANTO My 20pence/cents worth, I vote to make this the official page. We need to move with the times and the old page is outdated.

KristjanESPERANTO

@sdetweil said:

show how to resolve the integrity problem, without constant intervention

With “integrity problem” you are talking about how to add new modules to the list?

I’m also fine with your order of tasks :slightly_smiling_face:

is it you that becomes the maintainer?

A maintainer of this project, yes. But as I understand it, we can assign different teams with different roles for each project. So I don’t automatically have to become a maintainer of the core.

sdetweil

@KristjanESPERANTO integrity.

you said user error or vandal mess up the data

currently we don’t have different roles.

but that wasn’t my point.

I have enough on my plate and wouldn’t be able to maintain this

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)