-
Notifications
You must be signed in to change notification settings - Fork 57
Webpack build warning #26
Comments
Same issue here on a MacOS build... Will try to investigate this further. |
I'm also having this problem, has any progress been made on figuring out what's happening? |
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 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. |
@aguynamedben Having the same exact problem... did you ever come up with a solution? |
@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 wrongWebpack 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 <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 ( 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! 😠 |
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. |
Has anyone found a solution to this? |
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?
The text was updated successfully, but these errors were encountered: