Electron application engineering
Builds Electron features across isolated processes with narrow, validated communication and predictable native behavior.
electron-development
See how it helpsWhen is it useful?
Use when a desktop feature needs filesystem access or background work from the interface.
What does it help you do?
- Separates main, renderer and utility-process responsibilities.
- Exposes typed preload operations rather than unrestricted Node access.
- Validates incoming messages and handles windows and native dialogs consistently.
Try asking this
Add a file-import dialog through a narrow preload API, validating the request in the main process. Send an unexpected path and an invalid request shape from the renderer. The main process should reject both while allowing the normal native import flow.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Electron Development
Structure Electron applications around a strict separation of responsibilities: Main Process (OS integration, window lifecycle, IPC gatekeeper), Preload Script (minimal contextBridge surface), Renderer (sandboxed web UI), and utilityProcess (CPU-heavy or embedded Node.js server/worker workloads).
Multi-Process Architecture & utilityProcess
Never block the Electron Main process event loop with synchronous filesystem scans, SQLite queries, or embedded HTTP server request handling—blocking Main freezes window dragging, menus, and IPC across the entire app:
// Spawn an embedded Node.js backend or heavy worker via utilityProcess (uses Chromium Services API)
import { utilityProcess, MessageChannelMain } from 'electron';
import path from 'node:path';
const { port1, port2 } = new MessageChannelMain();
const serverProc = utilityProcess.fork(path.join(__dirname, 'server-entry.js'), [], {
env: { ...process.env, APP_USER_DATA: app.getPath('userData') },
stdio: 'pipe',
serviceName: 'local-backend',
});
serverProc.postMessage({ type: 'init' }, [port1]);
Typed contextBridge & Validated ipcMain.handle
- Preload (
preload.ts):- Pass only serializable data and narrow functions across
contextBridge.exposeInMainWorld('desktopApi', { ... }). - Never pass raw
ipcRenderer.oncallbacks that leak theIpcRendererEventobject; wrap listeners and return an explicitunsubscribe()function so React/Vue/Angular components can clean up on unmount.
- Pass only serializable data and narrow functions across
- Main Process (
ipcMain.handle):- Always check
event.senderFrame?.originagainst the expected app origin before executing privileged operations. - Return structured result objects (
{ ok: true, data } | { ok: false, code, message }) rather than relying on unhandled Error serialization, which strips custom properties across IPC.
- Always check
Window State, Native Dialogs & OS Polish
- Prevent visual flash on launch: Create
BrowserWindowwithshow: falseand a matchingbackgroundColor, then show it insidewin.once('ready-to-show', () => win.show()). - Persist and validate window bounds: Save
{ x, y, width, height, isMaximized }on resize/move (debounced), and on startup verify viascreen.getDisplayMatching(bounds)that the saved coordinates still intersect an attached monitor (handling unplugged external displays gracefully). - Parent-attached native dialogs: Always pass the active
BrowserWindowreference as the first argument todialog.showOpenDialog(win, ...)/dialog.showMessageBox(win, ...)so sheets attach properly on macOS and modal z-order is respected on Windows. - Custom protocol & deep links (
app.setAsDefaultProtocolClient):- On macOS, handle incoming
myapp://URLs viaapp.on('open-url', (event, url) => ...). - On Windows/Linux, extract the URL from
process.argvon initial launch and insideapp.on('second-instance', (event, commandLine) => ...), validating the URL structure strictly before routing.
- On macOS, handle incoming
Included files 1
SKILL.md
