Awesome! Thanks!

@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.

@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:

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

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 …

well we use it to control the test platforms.

Can you show me where?

That’s the point of npm ci it takes the package-lock.json to install and it don’t change it.

Wouldn’t that also be a good idea for the core? It would probably make sense to use the same strategy for the core as for the modules.

@rejas @karsten13

@Jalibu I just wanted to point you to this conversation. Thanks for your feedback! :-)

I’m thinking about adding a check for it to my project.

but something else will over the months.

“something else” will change the package-lock.json? How can that happen?

and we have to retrain all our users.

This is certainly a considerable disadvantage compared to approach 1.

Why npm ci doesn’t help? It doesn’t change the package-lock.json.

What is the best approach with the package-lock.json for modules?

The most common approach I see is that the package-lock.json is included in the repository and npm install is listed in the installation instructions. This has the disadvantage that the package-lock.json is sometimes changed during the installation and the user then has later problems doing a normal git pull to update the module.

I see two approaches that prevent this problem and wanted to know if you know of any others and what advantages or disadvantages you see in these approaches.

1. Remove package-lock.json from the repository (by adding it to .gitignore).

2. Use npm ci instead of npm install.

@vita10gy Nice :-) Don’t forget to add it to the module list.

This module is abandoned. In issue 14 you can read that the API stopped working. Try MMM-Flights instead.

I still can’t see a new version of gpsoauth or gkeepapi. In the issue they seem only talking about a workaround.

I’ve created a PR to fix this :-)

@uok825 said in Black Screen when news doesnt fetch:

“version”: “2.24.0”,
Node v16.20.2

Node 16 has reached End of Life. Please update node to version 20 and MM to 2.26.0 and check if the problem still occurs.

Got to the modules directory:
cd ~/MagicMirror/modules

Delete the “old” MMM-GoogleTasks directory:
rm -r MMM-GoogleTasks

Clone the fork:
git clone https://github.com/spydersoft-consulting/MMM-GoogleTasks

Change to the module directory:
cd MMM-GoogleTasks

Install dependencies:
npm install

🙂

@rrslssr According to issue 3, the API now requires a key and not even the developer has received one.

@mumblebaj Thanks for the hint! I’ve just updated the state description. But unfortunately it is still abandoned. The maintainer no longer responds to issues and PRs.

@mumblebaj Nice! Now all your modules have proper screenshots and tags. Thanks! :-)