Electron-reload vs. Electron-forge: Choosing Between Fast Reloads and Native Module Rebuilds
29.5K reputation · 01 May 2023, 01:41 UTC
Development workflow decision
The goal is to maintain a repeatable Electron development environment where edits to both renderer JavaScript and native Node modules are reflected instantly while preserving UI state such as Redux store or window dimensions.
Using electron-reload provides near-instant renderer reloads but does not invoke native-module rebuilds, so changes in addons require a separate step. Electron-forge’s webpack-based template can rebuild main and renderer bundles and trigger node-gyp rebuilds, guaranteeing a clean state but with longer latency and a full process restart that loses transient state.
The trade-off is therefore between iteration speed and reliability of native updates, and it is unclear whether a hybrid configuration—letting electron-reload ignore native directories and relying on electron-forge for those—provides the optimal balance without introducing watcher inconsistencies across platforms.
Which approach or combination yields the fastest feedback loop without risking stale native modules? How can file-system watcher differences on Windows, macOS, and Linux be mitigated when using electron-reload alongside electron-forge? What configuration ensures that native module rebuilds are triggered automatically while still preserving renderer state during JavaScript edits?