Please rethink Node 20 requirement and overly complex updates — adoption is at risk!

[garrettmac]

What problem do you want to solve with this change?

I have been following MagicMirror for years, and I’m extremely frustrated with the current direction. The recent updates have made the project significantly harder to adopt on the devices where it is most popular — Raspberry Pi and other low-powered hardware.
Specifically:

• Node 20 requirement — Many users, myself included, rely on older or ARM-based hardware that cannot run Node 20. Raspberrypi's cannot go past node 18 and default on node 10 so I just straight up cannot use it. I have to cherry pick in parts and god I hate doing this.
• Excessive dependencies and devDependencies — Every release now comes with a massive list of packages to install, some of which are clearly for development or edge cases (vitest, playwright, stylelint, etc.). This makes initial setup slow, fragile, and prone to breaking on non-standard environments.
  Breaking changes like node --run Features that only work on Node 20 break existing workflows and scripts. Users on older systems or custom hardware are left behind. It feels like there’s little consideration for backward compatibility.
• Frequent, unnecessary changes. Every release seems to add new scripts, new linting requirements, and new ways to run the mirror. While innovation is good, these changes break working setups and make the project feel unmaintainable for regular users.

What do you think is the correct solution?

MagicMirror should remain accessible and easy to set up on Raspberry Pi, minimal Linux boxes, and other low-power devices. Making it harder to install and run is actively shrinking your user base.
I urge the maintainers to:

• Reconsider the Node 20 requirement — support Node 18 LTS for at least the next year.
• Separate development dependencies from production dependencies clearly.
• Avoid breaking changes that invalidate working setups unless absolutely necessary.
• Keep installation and setup as simple as possible — for the users who actually run MagicMirror on the hardware it was built for.
  This project has so much potential, but the current direction risks alienating the very community that has kept it alive and thriving for over a decade. Please take a step back and think about the core users — not just the cutting-edge environment.

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[sdetweil]

If you use my script, it does not install the dev dependencies. You could do this by hand too

We use electron as the browser, and it continues to add new functionality and bug fixes. We cannot stay stable and be behind.

Node 24 is coming, with no support for arm32, v7l

You could use a platform browser instead of electron
But chrome is no longer for armv6l , and I suspect armv7l soon.

You can use one of my scripts to setup browser over server mode
See https://github.com/sdetweil/MagicMirror_scripts

[KristjanESPERANTO]

Hi @garrettmac,

Thanks for the detailed write-up — I'd like to understand your situation better before jumping to conclusions.

A few questions:

• Which Pi model and OS are you running? Our minimum is Node 22 (not 20). Node 22 has armv7l builds, so Pi 2 and newer can run it. The only models where Node 22 genuinely isn't available are the original Pi 1 and Pi Zero (armv6l) - this is documented in our requirements: Electron, which MagicMirror² uses as its app wrapper, does not support armv6l. Is that your situation?
• Which install command are you using? The recommended node --run install-mm doesn't install devDependencies — so I'm curious what you ran that pulled in vitest, playwright etc.
• What broke with node --run? npm run still works as before, so I'm not sure what's affected for you.
• You mention "cherry picking parts" — what does that look like in practice?
• Which changes specifically felt overly complex to you? From my perspective, core complexity hasn't really been increasing lately. Tests have grown more comprehensive — intentionally, to improve stability and catch regressions — but that's a different thing from the project being harder to use or set up.