Question
Electron-reload vs. Electron-forge: Choosing Between Fast Reloads and Native Module Rebuilds
Zo Maple
0 reputation · 01 May 2023, 01:41 UTC
99.3K views1
Loading…
0 reputation · 01 May 2023, 01:41 UTC
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?
30275 reputation · 01 May 2023, 11:47 UTC
Relying on Electron-forge's standard templates ensures reliability but forces a full process restart, which destroys transient UI state like Redux stores or window dimensions. Conversely, electron-reload is fast but blind to native Node.js addon changes, leading to 'module not found' or crashes when C++ code changes.
electronelectron-rebuild triggered by a specific watcher that monitors .node files or ~/build/ directories. This ensures that the heavy lifting of node-gyp only happens when native source changes.File system watchers vary across Windows (ReadDirectoryChangesW), macOS (fsevents), and Linux (inotify). To mitigate inconsistencies when using electron-reload alongside Forge:
node_modules and dist from the general electron-reload watcher to prevent infinite loops and high CPU usage.inotify_max_user_watches limit to prevent the watcher from failing on large-scale native builds.chokidar under the hood, as it provides the most consistent API for cross-platform file system events.To ensure native rebuilds are triggered automatically while preserving renderer state, do not bundle the rebuild into the main watcher. Instead, use a scoped script:
# Example: using concurrently to run two separate loops
concurrent "npm run dev:renderer" "watch --src ./src/native" --exec 'npx electron-rebuild'"Assumption: This assumes your native modules are compiled into a specific directory that can be watched. If you are using pre-compiled binaries, you only need to watch the package.json versioning changes.
Diagnostic Question: Are your native modules custom-written C++/Rust that you compile locally, or are you consuming pre-compiled npm packages? (This determines if you need to watch source files or just the build output.)
Use comments to ask for clarification. Post a solution as an answer.
3,510 reputation · 01 May 2023, 08:58 UTC
ignore array with globs such as node_modules/**/native_modules/** so the renderer restarts only on UI code, keeping native binaries untouched.watchOptions hook that runs npm run rebuild when files under src/native change, triggering node-gyp without a full Electron restart.usePolling:true and a 200 ms delay to counter ReadDirectoryChangesW hiccups; on macOS bump fseventsLatency to 150 ms; on Linux raise inotify_max_user_watches to 524288.Combining these settings yields near‑instant UI feedback while guaranteeing that native modules are rebuilt on change, all while keeping transient UI state intact.