Lors de mon récent stage, j’ai découvert pour la première fois l’immense base de code d’un produit. Il était difficile d’estimer la portée des changements, et je me demandais sans cesse « où ce code doit-il être référencé ? ». Je me suis dit qu’en imposant des frontières d’import via l’analyse statique (ESLint), il serait possible de maintenir plus durablement la qualité de l’architecture.
Je savais qu’il était aussi possible de créer des règles similaires avec eslint-plugin-boundaries. Mais pour une utilisation côté frontend, la configuration devenait plus complexe, et il était difficile d’imposer jusqu’à la forme du chemin d’import, même pour des targets autorisées.
J’ai donc créé eslint-plugin-import-boundary, où la structure des dossiers d’un projet JS (TS) devient la règle avec une configuration simple.
- Par défaut, un parent ne peut importer que les entrées publiques du répertoire enfant direct
- Le format du fichier d’entrée publique peut être défini (valeur par défaut : index)
- Il est possible de définir des fichiers (dossiers) communs afin que les modules partagés ne puissent être importés, dans cette portée, que depuis leur propre zone et les répertoires inférieurs.
Comme le projet en est encore à ses débuts, je serais ravi d’avoir vos retours et réactions. Merci !
- Documentation : https://nayounsang.github.io/eslint-plugin-import-boundary/
- Installation :
pnpm add -D eslint-plugin-import-boundary eslint
Aucun commentaire pour le moment.