Problem
Storage Explorer uses @electron/remote in 6 renderer files to call main-process APIs synchronously:
app/renderer/index.ts -- remote.getGlobal, remote.getCurrentWindow
app/renderer/SslCertificateManager.ts -- remote.process.argv, remote.app.getPath, remote.shell.openPath
app/renderer/MenuManager.ts -- remote.Menu.buildFromTemplate, remote.Menu.setApplicationMenu
app/renderer/MenuInitializer.ts -- remote.dialog.showMessageBox, remote.getCurrentWindow
app/renderer/Components/Editors/WebviewProxy.ts -- remote.webContents.fromId, remote.process.argv
app/renderer/providers/MenuManagerProvider.ts -- remote.Menu.buildFromTemplate, remote.Menu.getApplicationMenu
@electron/remote is the userland successor to the remote module that Electron removed from core in Electron 14. The Electron team marks it as not-recommended due to its use of synchronous IPC and exposure of main-process objects to renderers.
Keeping this dependency also forces us to drag an older transitive subtree along through electron -> @electron/get@2 -> got@11 -> cacheable-request@7 -> keyv@4.5.4, which generates ongoing dependency-hygiene noise.
Fix
Replace each @electron/remote call site with a pair of ipcMain.handle (main) and ipcRenderer.invoke (renderer) handlers. Bundle them into a small renderer-side wrapper module that mirrors the surface area currently consumed from remote.*. The trickiest call site is WebviewProxy.ts's use of remote.webContents.fromId; that requires a main-process proxy that holds the WebContents references and exposes their methods via IPC.
Once the imports of @electron/remote are gone:
- Remove
@electron/remote/main initialization from app/index.ts.
- Remove the
@electron/remote dependency from src/Standalone/package.json.
- Update
gulp/gulpfile.bundle.js and scripts/prune.js references.
- Run
npm run init and confirm the old transitive subtree drops out (npm ls keyv --omit=dev should be empty).
Side benefits
- Removes deprecated
@electron/remote package.
- Eliminates synchronous IPC from the renderer (small perceived-perf win and a security improvement).
- Future-proofs against Electron eventually dropping support entirely.
Problem
Storage Explorer uses
@electron/remotein 6 renderer files to call main-process APIs synchronously:app/renderer/index.ts--remote.getGlobal,remote.getCurrentWindowapp/renderer/SslCertificateManager.ts--remote.process.argv,remote.app.getPath,remote.shell.openPathapp/renderer/MenuManager.ts--remote.Menu.buildFromTemplate,remote.Menu.setApplicationMenuapp/renderer/MenuInitializer.ts--remote.dialog.showMessageBox,remote.getCurrentWindowapp/renderer/Components/Editors/WebviewProxy.ts--remote.webContents.fromId,remote.process.argvapp/renderer/providers/MenuManagerProvider.ts--remote.Menu.buildFromTemplate,remote.Menu.getApplicationMenu@electron/remoteis the userland successor to theremotemodule that Electron removed from core in Electron 14. The Electron team marks it as not-recommended due to its use of synchronous IPC and exposure of main-process objects to renderers.Keeping this dependency also forces us to drag an older transitive subtree along through
electron -> @electron/get@2 -> got@11 -> cacheable-request@7 -> keyv@4.5.4, which generates ongoing dependency-hygiene noise.Fix
Replace each
@electron/remotecall site with a pair ofipcMain.handle(main) andipcRenderer.invoke(renderer) handlers. Bundle them into a small renderer-side wrapper module that mirrors the surface area currently consumed fromremote.*. The trickiest call site isWebviewProxy.ts's use ofremote.webContents.fromId; that requires a main-process proxy that holds theWebContentsreferences and exposes their methods via IPC.Once the imports of
@electron/remoteare gone:@electron/remote/maininitialization fromapp/index.ts.@electron/remotedependency fromsrc/Standalone/package.json.gulp/gulpfile.bundle.jsandscripts/prune.jsreferences.npm run initand confirm the old transitive subtree drops out (npm ls keyv --omit=devshould be empty).Side benefits
@electron/remotepackage.