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