Can't resolve node modules in Electron main process

[yonigel]

Hi,

I'm using Electron and I'm trying to use node module in the main process (i.e. path, fs), but getting following error:

Module not found: Error: Can't resolve 'fs' in '...\src\main'

For main window I'm using:

mainWindow = new BrowserWindow({
width: 900,
height: 680,
webPreferences: {
nodeIntegration: true,
nodeIntegrationInWorker: true
},
fullscreen: true
});

I saw this issue but it should work in electron main process as far as I understand.

Am I missing something?

Thanks

[andywer]

Hey @yonigel,

that's a pretty generic electron question you have and seems unrelated to threads.js. So I'm afraid this is the wrong place to ask.

Code looks ok on first glance, though. Ask electron people on StackOverflow or so – they might be able to help you with that 😉

[strogonoff]

This seems related #44 and #211 and we’re having the same issue.

[strogonoff]

Solution in #211 is interesting but isn’t working so far; even after Webpack processed the module with dependencies (checking workerContents at runtime shows that it’s clearly a bundle and all the imports used in the worker are inlined) the code still can’t locate modules when worker is spawned. Looking into Webpack configuration.

[andywer]

I am not sure I can follow. If you bundle the worker, then why do modules need to be resolved at runtime? I guess you are using webpack externals?

[strogonoff]

No, did not have externals set up. Was getting “cannot find module” somehow when spawning a worker from string contents which had imported dependencies inlined by Webpack.

This had been since resolved through using threads-plugin and instantiating threads’ Worker based on filename. It is not immediately intuitive what is happening behind the scenes, but ultimately we’ve got it working! 😄

[andywer]

So you tried first, but couldn't use the BlobWorker at all? Would be great if you can find the time to sum up your approach and experience a little bit. Maybe we can improve it :)

[strogonoff]

Yes, BlobWorker has resulted into that import problem as well as worker_threads native Worker.

As it could have had something to do with Webpack behavior, I imagine it’d make sense to see if anyone else has issues with BlobWorker first before looking into this too much.

Here is an overview of experience, in case it’s useful in any way:

• This is in Electron main thread environment. There were never issues as long as the app was launched from command line. I just used native worker_threads’ Worker directly without issues.

• As was discovered later than I wish, when the app is launched by double-clicking the .app file, workers throw “Cannot find import” error on the first import encountered.

• To resolve that, at first bundling worker file with Webpack was done by setting worker file as additional entry point. The resulting bundle file was read into a string at runtime. Spawning a worker from that string produced the same “Cannot find import” error, and it happened with both the native Worker from worker_threads and after refactoring onto threads using its BlobWorker.

  (Worker contents string was confirmed to have imported dependencies inlined and minified by logging it before spawning the worker, but I won’t pretend I know exactly how Webpack did the inlining, so the issue could either be with that, or with how worker_threads’ Worker—and threads’ BlobWorker, which delegates to it a lot I suppose—evaluated that string.)

• Using regular Worker (through threads or directly via worker_threads) with worker bundled the above way had not been tried; whether that works or not I can’t say.

• Switching to threads’ regular Worker and threads-plugin (adding asarUnpack and removing extra Webpack entry point added earlier) did something that happened to resolve the problem with imports.

• A funky issue cropped up after that with electron-log, which—only in this worker environment—is somehow unable to obtain the log file path (I suspect its ways of obtaining either OS’s home directory or Electron app name do not return a string due to Node worker environment specifics), crashing worker as a result. So far I decided to avoid logging in our minimal worker functions, instead passing information up and doing all logging in the main thread.