Skip to content
This repository has been archived by the owner on Jun 17, 2020. It is now read-only.

Webpack build warning #26

Open
bellostom opened this issue Jul 5, 2017 · 7 comments
Open

Webpack build warning #26

bellostom opened this issue Jul 5, 2017 · 7 comments

Comments

@bellostom
Copy link

Hi

I get the below warning from webpack when importing a module from electron-remote

WARNING in ./~/electron-remote/lib/renderer-require.js 23:19-46 Critical dependency: the request of a dependency is an expression

And when the app loads, I get an error from the remote module of electron
file:///C:/DEVEL/node_modules/electron/dist/resources/electron.asar/renderer/api/remote.js
Uncaught Error: path must be a string
AssertionError: path must be a string
at Module.require (module.js:497:3)

Any ideas?

@iammichiel
Copy link

Same issue here on a MacOS build... Will try to investigate this further.

@bthallion
Copy link

I'm also having this problem, has any progress been made on figuring out what's happening?

@aguynamedben
Copy link

Was anybody able to get electron-remote working with Webpack? My project is based on electron-react-boilerplate, which uses Webpack to package code for the main and renderer processes.

I ran into an issue where I couldn't correctly provide the path to requireTaskPool. the README says requireTaskPool(require.resolve('./my-cool-module'));, and within the code another require.resolve is done here.

More details of what I ran into here: electron-react-boilerplate/electron-react-boilerplate#1587 Any comments on how these paths work would be appreciated.

@jfrux
Copy link

jfrux commented Nov 2, 2018

@aguynamedben Having the same exact problem... did you ever come up with a solution?

@aguynamedben
Copy link

@jfrux No, but I would very much like to. Some notes on how I've tried to wrap my head around with this. I went so far as to manually spin up an additional "backend" process manually, which was a pain, then just saying "well I'll just keep doing this stuff in the renderer a little bit longer".

WARNING: This is all speculation about the potential cause of the problem... it might be wrong

Webpack replacing of requires() happens at build time, require() in electron-remote seems to happen at run time. I think the issue is Webpack's (or Electron's) require() is overwriting Node's require() at build time. Then at run time, it all goes wrong.

I want to try renaming require to nodeRequire like this mentions.

<head>
  <script>
  window.nodeRequire = require;
  delete window.require;
  delete window.exports;
  delete window.module;
  </script>
  <script type="text/javascript" src="jquery.js"></script>
</head>

Maybe Electron's require is clobbering Node.js' require(), and electron-remote expects Node.js' require.

This line require.resolve()'s the module path you pass, but the README also notes you can require.resolve() yourself before passing the string to electron-remote. I guess it's no harm to double require.resolve() something.

This line also seems to do some tricks with require.

If none of that works, I need to learn more about what in God's name Webpack is doing to require(). It seems like if it's just Electron's require clashing, it might be simple to resolve. But I think it might be build-time Webpack processing the require.resolve(), generating some sort of integer, then at run-time it all goes wrong.

If none of that works, I'll probably end up trying to get rid of Webpack in my project. I've noticed that if you un-asar Slack (yarn add --global asar, asar extract /Applications/Slack.app/Contents/Resources/app.asar /tmp/slack-unasar) and inspect the code they ship, they simply don't use Webpack. I think Node 10 (i.e. Electron 3) support proper import statements, and there's probably a way to just use Babel + Node 10 to have access to modern ES6 without all the Webpack stuff. The downside to this is your startup time might be a little bit slower because you're requiring at run time instead of at build time like Webpack does, but the impact of that slowdown can be addressed with electron-link, and for my application I'd happily accept a slower startup time for dev speed and simplicity.

Alright, keep in mind that I am no authority on this stuff, I'm just trying to figure it all out like you. I'm almost certain some of my concepts of what is going on here are wrong. Let me know if there are things you can rule out or teach me about. 🙏

I'm sure it's part of the magic, but people need to leave require() alone! 😠

@aguynamedben
Copy link

More context: at some point I made this change to sort-of get things working https://github.com/electron-userland/electron-remote/pull/42/files

Also, because I eventually bailed to just keep using the renderer process for some semi-intensive work, I ended up finding the async library's queue data structure helpful in ensuring I don't do too much work simultaneously in the renderer. When my app launches, I have a timer.js file that uses setInterval to occasionally tee up some work. To avoid a state of high activity, the timer.js stuff adds to a queue with concurrency of 1. That way I can make sure only 1 crazy thing is happening at a time. Not the answer you're looking for, I know, but a sensible workaround.

@edcolyer
Copy link

edcolyer commented Jan 1, 2019

Has anyone found a solution to this?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants