It is a good try, Although most checklists are meaningless rather than useless. There are also wrong checks. (For example, MMM-ModuleMonkeyPatch doesn’t have node_modules directory. It doesn’t have node_helper.js at all.)

However, I would like to praise it because it is a good-looking list. It’s a good attempt.

In any case, dependency checking is information ordinary users cannot deal with even if they know it. Unless he is a developer, there is nothing he can do with that information.

Rather than performing a dependency check, it would be better to reveal the last update date or the number of unresolved issues to guess the module’s activation level or popularity.

Or, if you are going to parse package.json anyway, I think it could be used to organise installation methods, etc.

@0m4r
I was the original author of that module. ;)
Basically, if any module could emit any notification and it could be translated properly, it will work.
You can define your customization with payloadConverter and notification in config.js

notification: "SOME MODULE NOTI",
payloadConverter:(payload)=>{
        return  "windy night spring"  // <= query text for the image.  
}

Currently, this module is managed by brianHelper

@sifuhall
Maybe like this;

Some test words are censored and removed already, so you cannot see them in title (and in description). (test words are “FBI”, “in data”, ‘man’, “to”)

Anyway, it is a tiny modification of the original Mich’s default module. So real monetized reward is not fair (at least, I think)
You can get it here;
https://github.com/MMRIZE/MMM-anotherNewsFeed

But if you want more than the little modification, anyway contact me.

MMM-ModuleMonkeyPatch

MagicMirror module to make monkey-patching other modules
https://github.com/MMRIZE/MMM-ModuleMonkeyPatch

No screenshot, because it works in the background.

Why?

When you need some modification of existing modules but do not want to edit the original source code to prevent conflicts on upgrade/update.

But… I think rare people will use this module. :D. This was my half-day weekend killing-time project.

Usage example;

• When you want to change the rendering of a specific module, but not sufficient with only CSS handling. So you have to modify getDom(), you can override that method with this module.
• When you want to insert a logic into some module to handle your specific notification, you can override notificationReceived() with this module.

Or many other things, without worrying of update/upgrading the original module on direct modification.

Limitation

• This module works after ALL_MODULES_STARTED notification, which means you cannot override start method.

My desktop clock? calendar? whatever…

• RPI 4B
• 1920x480 Touch LCD /w case unit from AliExpress.

with some modules modification and scripts, it could become a 9to5 office gadget.

I need some more angled plugs for a better look, anyway 90% done.

Dear community,
Recently I got a message from CalendarLabs, who is providing ical of MM’s default config.js.sample. They had some problem from too many/frequent request from MM (because it is included in config.js.sample)

Around three thousand MagicMirror systems are making a huge amount of requests, impacting our service (similar to DDoS). Some IPs even send more than 20 requests per minute.

Also, Most of them using an old version of the ics URL, which will be phased out from 30th July.

So, all the subscribers should get their unique URL for their applications(so that they won’t get blocked for exceeding the limits of 36 requests per day for holiday calendars).

Also, they should visit the ical page after creating a free login, if they want to get notified when they exceed the limit or there is any update related to the ics they are using (the subscriber ID get associated with the logged-in users when it is within same user session)

Any ics subscriber exceeding the request limit will receive notifications on their calendar from 30th July.

Not to request too many times/frequently. It consumes others’ resources.
I think 30 mins or a few hours is enough to reveal updates. Really do you guys need real-time updates?(Especially for holiday? it will not be changed in a day. :D )

I suggest you and the community expand package.json to regularise the details of the module. (recommended but optional)
For example;

{
  "name": "mmm-something",
  "version": "1.0.0",
  ...
  "mm" : {
    "communityId" : "johndoe",
    "community" : "MagicMirror forum",
    "screenshot" : "https://somewhere.com/screenshot.png",
    "install" : "https://github.com/johndoe/mmm-something/README.md#installation",
    "update" : "...",
    "email" : "johndoe@somewhere",
    "required: {
      "mm" : "2.25",
      "node" : "18.0"
    },
    "notice" : [
      "This will not work in Windows.",
      "Pre-dependency required. Please readme."
    ]
  }
}

The fields are my imagination. Maybe the community can reach an agreement on rules.

@flemmingss
I’m trying to build a new X3 from the scratch, which will respect default MM’s behaviours, will be independent of legacy/external momentJs or other 3rd parties, will be more modular and lighter than X2 and with a few new features.
But it needs more days or weeks to release. I wish I have more dedicated time to that work. Sorry.

@pat59
Or just remove “updatenotification” module from config. Trust me, it would be better.

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.