refactor(types): Renderer/Main-Grenze schliessen und bewachen - #27
Merged
Baldri merged 1 commit intoAug 28, 2026
Merged
Conversation
`tsconfig.json` covers only src/renderer, src/shared and src/preload, but TypeScript follows imports past that boundary. Four renderer files imported types straight from src/main, and each one grafted a piece of the main-process module graph onto the renderer's type-check — a graft that grows on its own whenever the main-process file gains an import. That is not hypothetical. A guard import added to hybrid-orchestrator.ts (#26) extended the renderer's graph through orchestrator-store.ts down to src/main/database/index.ts, whose `sql.js` dependency ships no types and has no @types package installed. `npm run typecheck` failed with TS7016 in a file nobody had edited. `RiskLevel`, `SensitiveDataType`, `SensitiveDataMatch`, `SensitiveDataScanResult` and `UploadPermissionRequest` move to `src/shared/privacy-types.ts` — the last of these embeds a scan result, so the five are one cluster and none of them touches main-process code. Both defining modules re-export the names, so main-process importers are unchanged. The guard matters more than the move. A single import line will not be caught in review, and the failure it causes surfaces somewhere else entirely — in a file the author never opened. `tests/unit/renderer-process-boundary.test.ts` scans every renderer source and fails with the offending file, the offending line, and what to do about it. Verified to discriminate, both import forms: - a static `from '../../main/...'` smuggled into a renderer store -> red - a dynamic `import('../../main/...')` -> red, same test 1411 tests green, typecheck exit 0, build:main and build:renderer exit 0. grep over src/renderer finds no boundary crossing, with a positive control in the same run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Was
Die letzten vier Stellen, an denen der Renderer Typen aus dem Electron-Hauptprozess importierte, sind aufgelöst — und ein Test hält die Grenze künftig geschlossen.
Warum das kein Stilthema ist
tsconfig.jsondeckt nursrc/renderer,src/sharedundsrc/preloadab. TypeScript folgt Importen aber über die Grenze hinaus. Jeder solche Import pfropft ein Stück des Hauptprozess-Modulgraphen auf den Typecheck des Renderers — und dieses Pfropfreis wächst von selbst, sobald die Hauptprozess-Datei einen neuen Import bekommt.Genau das ist passiert: Der Guard-Import in
hybrid-orchestrator.ts(#26) verlängerte den Typgraphen des Renderers überorchestrator-store.tsbis insrc/main/database/index.ts, dessensql.js-Abhängigkeit keine Typen mitbringt und für die kein@types-Paket installiert ist.npm run typecheckfiel mit TS7016 — in einer Datei, die niemand angefasst hatte.Änderungen
RiskLevel,SensitiveDataType,SensitiveDataMatch,SensitiveDataScanResultundUploadPermissionRequestliegen jetzt insrc/shared/privacy-types.ts. Der letzte bettet ein Scan-Ergebnis ein, die fünf sind also ein Cluster, und keiner hängt an Hauptprozess-Code. Beide definierenden Module re-exportieren die Namen, bestehende Importeure bleiben unverändert.Der Wächter ist der wichtigere Teil. Eine einzelne Importzeile fällt im Review nicht auf, und der Fehler, den sie verursacht, taucht ganz woanders auf — in einer Datei, die der Autor nie geöffnet hat.
tests/unit/renderer-process-boundary.test.tsdurchsucht jede Renderer-Quelle und meldet Datei, Zeile und was zu tun ist.Tests
npm test→ 1411 passed | 29 skipped (95 Dateien), Exit 0 ·npm run typecheck→ Exit 0 ·build:mainundbuild:renderer→ Exit 0Kein bestehender Test verändert.
Nachweis, dass der Wächter diskriminiert — beide Importformen:
from '../../main/security/...'in einen Store geschmuggeltimport('../../main/database/index')Und der Grep-Nachweis mit Positivkontrolle im selben Lauf: null Übergriffe, während dieselbe Suche die neuen
shared-Importe findet. Ein Nullbefund ohne Positivkontrolle wäre keiner.Review-Punkte
Der Wächter arbeitet auf dem Quelltext, mit einem regulären Ausdruck über Import- und
import()-Formen. Das ist bewusst: er liest ein paar Dutzend Dateien, braucht keine Transformation und hängt an keiner Uhr. Eine exotische Schreibweise — etwa ein über eine Konstante zusammengesetzter Pfad — würde er übersehen; dagegen steht der erste Test, der sicherstellt, dass er überhaupt Dateien findet.Die Grenze gilt in eine Richtung.
src/maindarf weiterhin aussrc/sharedlesen, und das tut es. Geprüft wird nur, dass der Renderer nicht in den Hauptprozess greift.preloadist nicht abgedeckt. Dort wäre ein Import ausmainarchitektonisch ebenfalls fragwürdig, aber es gibt heute keinen, und ich habe die Prüfung nicht auf Verdacht ausgeweitet.🤖 Generated with Claude Code