Move default modules into own repositories (git submodules).

[Bruce17]

Hi,

I'm just wondering why the default modules are added to the main magic mirror project.

Is it an option for you to move them into own repositories and add them again via git submodules? I've worked with git submodules in the past and have made some good experiences with it.

[paviro]

Makes sense I approve!

…

Am 06.02.2017 um 15:07 schrieb Michael ***@***.***>: Hi, I'm just wondering why the default modules are added to the main magic mirror project. Is it an option for you to move them into own repositories and add them again via git submodules? I've worked with git submodules in the past and have made some good experiences with it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[roramirez]

Sound good but for this I think we need create a organization where it's pushed all modules and core splitted way like part of a ecosystem like NodeJs

[paviro]

I approve. One repo for every module would be ideal in my opinion :)

…

Am 06.02.2017 um 17:00 schrieb Rodrigo Ramírez Norambuena ***@***.***>: Sound good but for this I think we need create a organization where it's pushed all modules and core splitted way like part of a ecosystem like NodeJs — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Bruce17]

Sounds good. Let me know if I can help you.

[MichMich]

What would be the added benefit for doing this? I don't want to overcomplicate things.

[Bruce17]

TL;DR separation of concerns

• You get rid of hard coded modules in your code.
• Improve maintainability of modules.
  => In my opinion, you can solve the issue Broken, unmaintained upstream "rrule" fails parsing calendar EXDATEs and UNTIL correctly #565 by moving it into an external module. There is an issue with rrule, because it is not properly installed via npm (see https://github.com/MichMich/MagicMirror/blob/master/modules/default/calendar/vendor/ical.js/package.json).
• Every module has its own issue/pr feed. Now everything is put into the main module.
• Better control of used module versions.

[MichMich]

Thanks for you input. I really appreciate your contribution.

Though I don't think the mentioned benefits validate the big change. We're not running into big issues caused by hard coded modules. Having an separate issue/pr feed is a personal preference. And honestly, I'd like to keep all MagicMirror related stuff together.

Biggest issue would be that I need to move it to an organisation account. Which I currently not really want to do.

Not saying it will not or never happen. Just not based on the above mentioned arguments.

[fewieden]

On the one hand I agree with Michael, as long as there not many issues about the modules, there is no need to have a seperate issue/feed, but on the other hand in my oppinion it would be a benefit if the user doesn't like a module update to stay on the current version and is still able to update the code of MagicMirror without having to touch any code to make changes.

[MichMich]

@fewieden I think that's an edge case. Users that worry about those kinds of thing are probably able to make a fork and solve it that way. My biggest focus in this project is to keep things simple. Ripping it apart would, IMHO, make things unnecessary complicated.

[fewieden]

I just can tell from my experience as I helped a lot of users on the forum with remote desktop sessions, that they modified stuff and were unable to update. Those who contribute here could do it without the submodules. I'm neutral on this topic I can understand both sides.

[MichMich]

Since I don't see this happening anytime soon, I close the issue for now. Feel free to reopen this issue.