Error loading main module tries to build temp file, fails, reports wrong error

[dathbe]

OS

Debian 10

NodeJS Version

22

MagicMirror² Version

2.31

Remote Control Version

2.5.3

Did you try using just Remote Control alone with MM?

• I have and the error still happening

Description

MMM-Remote-Control tries to load /MMM-RAIN-MAP/MMM-RAIN-MAP.js, which fails initially, so it tries to build a temp.js file. Loading the reformatted temp.js also fails, which causes an error in the logs.

The error reported on the actual js file and the error reported on the temp.js are different, and only the latter gets reported in the log (which I do not believe is the real error).

temp.js is not deleted, so it just stays there.

Expected behavior

1. Ideally, we could somehow tweak Remote-Control to load MMM-RAIN-MAP properly
2. The proper error should be reported if not.
3. The temp.js file should be cleaned up.

Current behavior

With module MMM-RAIN-MAP, MMM-Remote-Control tries to load the main js file, fails in node_helper.js at line 328.

The apparent error is with the very end of MMM-RAIN-MAP.js where there is an additional (Log) after the usual final }. I could not tell you why it's there, what it does, or why MMM-Remote-Control does not like it (the MMM-RAIN-MAP module works fine on its own).

[2025-04-12 13:29:28.265] [WARN]  ReferenceError: Log is not defined
0|mm  |     at Object.<anonymous> (~/MagicMirror/modules/MMM-RAIN-MAP/MMM-RAIN-MAP.js:28:158622)
0|mm  |     at Module._compile (node:internal/modules/cjs/loader:1569:14)
0|mm  |     at Module._extensions..js (node:internal/modules/cjs/loader:1722:10)
0|mm  |     at Module.load (node:internal/modules/cjs/loader:1296:32)
0|mm  |     at Module._load (node:internal/modules/cjs/loader:1115:12)
0|mm  |     at c._load (node:electron/js2c/node_init:2:18008)
0|mm  |     at TracingChannel.traceSync (node:diagnostics_channel:322:14)
0|mm  |     at wrapModuleLoad (node:internal/modules/cjs/loader:227:24)
0|mm  |     at Module.require (node:internal/modules/cjs/loader:1318:12)
0|mm  |     at require (node:internal/modules/helpers:136:16)
0|mm  |     at Class.loadModuleDefaultConfig (~/MagicMirror/modules/MMM-Remote-Control/node_helper.js:328:7)
0|mm  |     at ~/MagicMirror/modules/MMM-Remote-Control/node_helper.js:280:14
0|mm  |     at FSReqCallback.oncomplete (node:fs:199:5)

The above logging had to be added.

The catch block for line 328 says to build a temp.js file to hopefully correct some issues that apparently come from reading bundled apps. That temp.js file is created, but it's no use. Adding some logging shows a DIFFERENT error on the temp file than on the original file:

[2025-04-12 13:54:20.042] [WARN]  TypeError: Cannot read properties of undefined (reading 'style')
0|mm  |     at ~/MagicMirror/modules/temp.js:29:16027
0|mm  |     at ~/MagicMirror/modules/temp.js:29:149531
0|mm  |     at Object.<anonymous> (~/MagicMirror/modules/temp.js:29:158621)
0|mm  |     at Module._compile (node:internal/modules/cjs/loader:1569:14)
0|mm  |     at Module._extensions..js (node:internal/modules/cjs/loader:1722:10)
0|mm  |     at Module.load (node:internal/modules/cjs/loader:1296:32)
0|mm  |     at Module._load (node:internal/modules/cjs/loader:1115:12)
0|mm  |     at c._load (node:electron/js2c/node_init:2:18008)
0|mm  |     at TracingChannel.traceSync (node:diagnostics_channel:322:14)
0|mm  |     at wrapModuleLoad (node:internal/modules/cjs/loader:227:24)
0|mm  |     at Module.require (node:internal/modules/cjs/loader:1318:12)
0|mm  |     at require (node:internal/modules/helpers:136:16)
0|mm  |     at Class.loadModuleDefaultConfig (~/MagicMirror/modules/MMM-Remote-Control/node_helper.js:339:11)
0|mm  |     at ~/MagicMirror/modules/MMM-Remote-Control/node_helper.js:280:14
0|mm  |     at FSReqCallback.oncomplete (node:fs:199:5)

Again, the above logging had to be added for debug purposes.

After failing on the temp.js, vanilla Remote-Control reports the following error, which is both incorrect and not particularly helpful

[2025-04-12 13:29:28.422] [ERROR] [MMM-Remote-Control] Could not load main module js file. Error found: Cannot read properties of undefined (reading 'style')

(I confirmed this to be MMM-RAIN-MAP by some added logging, #330 .)

The temp.js file is never deleted.

So Remote-Control catches an error that (maybe?) it shouldn't catch.
Tries to build a temp.js file to get around an error that is not present.
Reports the wrong error because it reports the error on the temp.js.
And then doesn't delete the temp.js it creates.

Possible solution

Either be more lenient on the ending (Log) in the MMM-RAIN-MAP file, or more accurately report that error? (I tried to delete it from MMM-RAIN-MAP, but it breaks that module).

More carefully select which files get written to temp files?

Clean up temp files after attempt?

Steps to reproduce

Install MMM-RAIN-MAP
Install MMM-Remote-Control
Check logs

Log

See above

config.js

n/a

Additional info

No response

[dathbe]

Additional thoughts on ways to address this:

Config option for something like ignoreModules where modules can be explicitly ignored.
Instead of having nested catch blocks with the same e error variable, have two different error variables and return either both or the first one (based on the real file instead of the temp.js.

Unfortunately, I don't even know what Remote-Control is trying to do when it "loads" a module, so I'm not a ton of help.

[KristjanESPERANTO]

As far as I understand it, it's about getting the default options and values of the modules. This is somehow different for the bundled modules than for the normal ones. I don't know if I'll be able to take a closer look soon. If someone else can do that, I would appreciate it.

[dathbe]

Just to be clear, “bundled” means the default apps that come with vanilla MM?

Wouldn’t it be easier and more precise to identify theses by filepath instead of “if error, catch”?

[KristjanESPERANTO]

Just to be clear, “bundled” means the default apps that come with vanilla MM?

No, with "bundled" I mean modules like MMM-RAIN-MAP which are developed in TypeScript and have a build process to create the final file(s). Checkout the MMM-RAIN-MAP.js - it doesn't look like a normal module js file.

Wouldn’t it be easier and more precise to identify theses by filepath instead of “if error, catch”?

Identifying is not the problem. The problem is to load the defaults from those files.

[KristjanESPERANTO]

Can you please check if this issue also occurs if you don't use pm2? I can't reproduce it 🤔

[dathbe]

No, with "bundled" I mean modules like MMM-RAIN-MAP

Oh, so the catch-then-create-temp.js is actually designed for modules like this. I'll have to look at it more closely and see if I can come up with a solution.

Can you please check if this issue also occurs if you don't use pm2? I can't reproduce it 🤔

I'd be happy to, but I don't actually know what the alternative method is.

[dathbe]

I mean, changing line 334 to:

const newContent = `const Log = console;const document = navigator = window = {};document.createElement = function() { return {}; };\n${fs.readFileSync(filename, "utf8").replace('(Log)','')}`;

Stops throwing errors. It just removes the weird "(Log)" from the end of the file. I couldn't tell you if the file is properly loaded as I do not use Remote-Control for anything having to do with RAIN-MAP.

And yes, I confirmed that's the only instance of "(Log)" in the file. But that's obviously going to be hit or miss for other files of this type.

A slightly safer though more verbose way of doing it would be something like:

var fileContent = fs.readFileSync(filename, "utf8");
if (fileContent.endsWith('}(Log);\n')) {
  fileContent = fileContent.substring(0, fileContent.length - 7) + ';\n';
}
const newContent = `const Log = console;const document = navigator = window = {};document.createElement = function() { return {}; };\n${fileContent}`;

Sometime someone is going to have to explain to me why some javascript files have a semicolon at the end of every line and others don't.

[KristjanESPERANTO]

I'm on vacation for the next few days 😎 I'll take a look at it afterward.

[KristjanESPERANTO]

Thanks for the PR!

Unfortunately, I cannot recreate the problem. Not even with pm2. Since the manipulation of the bundled modules is already a bit hacky, I would like to understand the problem better before I merge the PR.

Can you please test with the following minimal config.js if the problem occurs on your system with it?

let config = {
  address: "0.0.0.0",
  port: 8080,
  basePath: "/",
  ipWhitelist: [],
  logLevel: ["INFO", "LOG", "WARN", "ERROR", "DEBUG"],
  modules: [
    {
      module: "MMM-RAIN-MAP",
      position: "top_left"
    },
    {
      module: "MMM-Remote-Control",
      position: "bottom_left"
    }
  ]
};

/** ************* DO NOT EDIT THE LINE BELOW ***************/
if (typeof module !== "undefined") {  module.exports = config; }

I'd be happy to, but I don't actually know what the alternative method is.

Run that in the command line:

cd ~/MagicMirror
npm run start

Sometime someone is going to have to explain to me why some javascript files have a semicolon at the end of every line and others don't.

Most developers use semicolons at the end of every line in JavaScript for clarity and to avoid issues with Automatic Semicolon Insertion (ASI), while others skip them, trusting ASI to handle it. I would say that it's a matter of coding style preference.

[dathbe]

Seen. Will do when I have the opportunity and will report back.