Während meines jüngsten Praktikums habe ich zum ersten Mal eine sehr große Codebase eines Produkts erlebt. Es war schwer abzuschätzen, welchen Einfluss Änderungen haben würden, und ich fragte mich immer wieder: „Von wo aus sollte dieser Code referenziert werden?“ Ich dachte, dass sich die Architekturqualität stabiler halten ließe, wenn man Import-Grenzen per statischer Analyse (ESLint) erzwingt. Mit eslint-plugin-boundaries wusste ich bereits, dass sich ähnliche Regeln erstellen lassen. Für den Einsatz im Frontend wurde die Konfiguration jedoch recht komplex, und selbst bei erlaubten Targets war es schwierig, auch die Form der Import Paths zu erzwingen.
Deshalb habe ich eslint-plugin-import-boundary entwickelt, bei dem mit einfacher Konfiguration die Ordnerstruktur eines JS(TS)-Projekts zur Regel wird.
- Standardmäßig darf ein übergeordneter Ordner nur den public entry seiner direkten untergeordneten Verzeichnisse importieren
- Das Dateiformat für public entry lässt sich festlegen (Standard: index)
- Gemeinsame Dateien (Ordner) können definiert werden, sodass Shared Modules innerhalb dieses Bereichs nur von sich selbst und untergeordneten Verzeichnisbereichen importiert werden können.
Da es sich noch in einer frühen Phase befindet, freue ich mich über Feedback und Reaktionen. Vielen Dank!
- Dokumentation: https://nayounsang.github.io/eslint-plugin-import-boundary/
- Installation:
pnpm add -D eslint-plugin-import-boundary eslint
Noch keine Kommentare.