webpack: Target for "electron-renderer" shouldn't have `browser` in `resolve.mainFields`
Bug report
What is the current behavior?
Issue #6811 assumption is wrong. Electron renderer is not only a browser, it utilities the node power.
Each web page in Electron runs in its own process, which is called the renderer process. In normal browsers, web pages usually run in a sandboxed environment and are not allowed access to native resources. Electron users, however, have the power to use Node.js APIs in web pages allowing lower level operating system interactions. https://electronjs.org/docs/tutorial/application-architecture
When target browser, you’ll lose all the node power.
If the current behavior is a bug, please provide the steps to reproduce.
What is the expected behavior?
The pr to the issue #6811 should be reverted.
Other relevant information: webpack version: 4.16.5
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 16
- Comments: 21 (3 by maintainers)
Commits related to this issue
- fix: make posting key not experimental ⏬ also move contentEditable (EDIT on Review) as experimental 🏪 cache whitelisted experimental feature on localStorage culprit👉 https://github.com/webpack/web... — committed to g-u-c/guc-desktop by DrSensor 6 years ago
- fix: make posting key not experimental ⏬ also move contentEditable (EDIT on Review) as experimental 🏪 cache whitelisted experimental feature on localStorage culprit👉 https://github.com/webpack/web... — committed to g-u-c/guc-desktop by DrSensor 6 years ago
Another real-world example where this is a problem:
browserfield to load the browser version of XMLHttpRequest - https://github.com/socketio/engine.io-client/blob/master/package.json#L73But even conceptually, it doesn’t make much sense to me to treat Electron as just a browser. If that were true, why does webpack itself has a special target for
electron-renderer?Another problematic example is with axios, an HTTP client that supports both browser (XHR) and node (http). It comes with two backends and it is quite common to use both in an Electron renderer (XHR for regular GETs and node API for streaming support). However, it has a
browserfield in itspackage.jsonand when packed with webpack, the node backend is discarded… We have to manually vendorize its node backend to workaround.I found temporary solution for electron-renderer target :
CC: @cxa @DrSensor @mx2323
All this time wasted on troubleshooting, thousands of developers suffering because of one guy’s preference. I’ve seen literally more than 20 issues being tracked and ignored because of this. Devs are using forks of popular libraries because there’s no way to overcome this on mature projects. Whole point of Electron is having Node’s powerful capabilities on a browser renderer, with or without
nodeIntegration. Been in the open-source world for almost 2 decades and I thought community driven software was built on majority’s opinion. Oh well. 🤷🏻♂️https://github.com/webpack/webpack/issues/6796 . 😦
Instead of using
electron-renderer, usetarget: 'node'and includeelectronin externals.Our application in renderer process uses a lot of node.js features. With new version of the webpack we cannot do this. here is an example, we use package
ipfor our needs.ipuses node.js API (require(‘os’)), what do we have now -osis shimmedYes, you can use Node.js in the renderer too, but if I import a module that works in both Node.js and the browser, I would personally prefer the browser version which uses browser APIs.
@cxa Can you provide a real-world example of when this is problematic?
any update on a fix for this?
This also breaks the
wsWebSocket package.Webtorrent is affected too: webtorrent/webtorrent#1597