Eine klare und gut durchdachte Projektstruktur ist entscheidend für die langfristige Wartbarkeit einer Electron-Anwendung. In diesem Artikel lernst du eine empfohlene Ordnerstruktur sowie erprobte Konventionen kennen.

01 · Abschnitt

Empfohlene Ordnerstruktur

Eine saubere und skalierfähige Struktur sieht so aus:

text Projektstruktur 
electron-app/
├── src/
│   ├── main/                    # Main-Prozess (Node.js)
│   │   ├── main.js
│   │   ├── window-manager.js
│   │   ├── menu.js
│   │   ├── tray.js
│   │   └── ipc/
│   │       ├── handlers/
│   │       └── channels.ts
│   ├── preload/                 # Preload-Skripte
│   │   └── preload.js
│   ├── renderer/                # Renderer (Web-Frontend)
│   │   ├── index.html
│   │   ├── main.ts
│   │   ├── styles/
│   │   └── components/
│   └── shared/                  # Gemeinsam genutzte Typen und Hilfsfunktionen
│       └── types.ts
├── package.json
└── electron.vite.config.ts
02 · Abschnitt

Wichtige Prinzipien

Halte dich an diese Grundregeln:

  1. Strikte Trennung von Main und Renderer Der Renderer darf niemals direkt auf Node.js-APIs zugreifen. Alle systemnahen Operationen müssen über den Main-Prozess oder sicher exponierte Preload-Funktionen laufen.

  2. Zentrale IPC-Schicht Alle IPC-Handler sollten in src/main/ipc/ organisiert sein. Verwende TypeScript-Interfaces für die Typisierung der Nachrichten.

  3. Verantwortlichkeiten klar trennen

    • window-manager.js → Alles rund um BrowserWindow
    • menu.js → Application Menu und Context Menus
    • ipc/handlers/ → Alle invoke/handle und send/on Handler
03 · Abschnitt

Dateinamen-Konventionen

text Empfohlene Namensgebung 
main.js                 → Einstiegspunkt des Main-Prozesses
preload.js              → Einziger sicherer Brückenpunkt
window-manager.js       → Fenster-Erzeugung und -Verwaltung
menu.js                 → Menü-Logik
tray.js                 → System-Tray
ipc/handlers/           → Alle IPC-Handler (zentrale Sammlung)
04 · Abschnitt

Häufige Stolperfallen bei der Projektstruktur

Alles in eine einzige main.js packen

Viele Einsteiger schreiben 400–600 Zeilen in eine einzige main.js. Das wird schnell unübersichtlich. Teile die Logik früh in kleinere Dateien auf (window-manager, menu, ipc) — nachträglich umzustrukturieren ist immer mühsamer als von Anfang an Disziplin zu halten.

Direkter Zugriff des Renderers auf Node-APIs

Einer der häufigsten Sicherheitsfehler. Sobald contextIsolation: true aktiviert ist (und das sollte sie immer sein), bricht der direkte Zugriff auf fs, child_process oder electron im Renderer. Der einzige saubere Weg ist die Preload-Brücke mit contextBridge.exposeInMainWorld.

Pfade hart codieren statt app.getPath

Userdaten gehören in app.getPath('userData'), Logs in app.getPath('logs'), Downloads in app.getPath('downloads'). Wer Pfade wie ~/MyApp/data hart codiert, bricht auf Windows und macOS. Electron normalisiert das per Plattform — nutze die API.

Kein gemeinsamer Typen-Layer für IPC

Wenn Main und Renderer unterschiedliche Typen für dieselbe IPC-Nachricht haben, baust du Bugs ein, die der Compiler nicht findet. Lege gemeinsame Interfaces in src/shared/ ab und importiere sie auf beiden Seiten — das ist der wichtigste Hebel für Wartbarkeit.

Build-Output und Source vermischen

Der Build-Output (dist/, out/, build/) gehört nicht ins src/-Verzeichnis und nicht ins Git. .gitignore und electron-builder.yml/forge.config.js sauber konfigurieren — sonst werden versehentlich Build-Artefakte mitversioniert oder im Asar-Bundle eingepackt.

package.json ohne main-Field

Electron startet das Skript, das im main-Feld der package.json steht. Fehlt es, sucht Electron index.js im Root — was selten erwünscht ist. Pflicht: "main": "src/main/main.js" (oder den passenden Pfad).

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Einstieg

Zur Übersicht