@reticlehq/electron reaches the two places the renderer cannot: the IPC boundary, and capturePage().
Version 2.8.0. Apache 2.0. Depends on @reticlehq/core. Peer dependency: electron >= 22. No build step.
Why it exists
In Electron the interesting failures happen across IPC. The renderer asks the main process for something, the main process quietly fails, and the renderer-side SDK sees nothing at all. That reads as “this app makes no backend calls” rather than “you are blind to them”.Exports map
There is no. export. Two subpaths only.
The preload
ipc://<channel> with initiator: 'ipc':
It then exposes
window.__reticleIpc through the context bridge, with three members used by the SDK rather than by you:
The main process
installReticleCapture(win): void is a no-op on null or undefined, tracks the window until it closes, and registers the capture handler once for the whole app.
The handler calls webContents.capturePage(), writes the PNG into a per-process 0700 captures directory as reticle-capture-<n>.png, and returns the file path rather than the bytes, because the transport has a 64KB cap. It returns null on an empty image or any error, and it refuses fullPage: true explicitly rather than silently returning a viewport shot.
Renderer wiring
The renderer still needs the SDK. A packaged app is a production build, so the connect call has to opt in:reticle({ desktop: true }).
Desktop setup in full
Electron and Tauri wiring, and what
reticle doctor checks for each.