Refactorisation lint : état d'avancement

Étapes accomplies

• Garde-fous CI : le workflow Quality exécute systématiquement ESLint (script lint:ci) et la vérification TypeScript (typecheck) sur chaque push et pull request, ce qui couvre les exigences de l'étape 1 du plan.【F:.github/workflows/quality.yml†L1-L38】
• Baseline tolérante : la configuration ESLint actuelle abaisse les règles les plus bruyantes au niveau warn, tandis que lint:ci n'échoue que sur les erreurs. Cela correspond à l'étape 2 (option A) pour accepter l'état existant tout en empêchant les régressions supplémentaires.【F:.eslintrc.cjs†L1-L60】【F:package.json†L5-L38】

Étape 3 : corrections automatiques sans risque

Ce qui est accompli

• Les derniers périmètres non traités (routes, classes, scripts hérités tvkit) ont été formatés avec Prettier et eslint --fix --fix-type problem, ce qui ferme le chantier "mise en forme automatique" sur l'ensemble du front. On le constate notamment sur le layout de connectivité, les classes de plateformes et les usines TV désormais alignés sur le style partagé.【F:src/routes/(connectivity)/+layout.svelte†L1-L173】【F:src/lib/classes/platforms/identifier.ts†L1-L60】【F:src/lib/classes/platforms/tvLauncher.ts†L1-L31】
• Les composants Svelte normalisés lors des itérations précédentes conservent une structure stable (imports triés, attributs Svelte regroupés), ce qui facilite l'identification des avertissements métiers restants et limite les diffs parasites pour la suite de la refactorisation.【F:src/lib/components/common/Modal.svelte†L1-L270】【F:src/lib/components/area/Widget.svelte†L1-L123】

Étape 4 : durcir progressivement les règles

L'exécution de npm run lint ne remonte plus d'erreurs bloquantes mais laisse 368 avertissements, majoritairement des variables inutilisées, des any résiduels et des déclarations dans des switch LG hérités.【f5800d†L1-L128】 Pour franchir le palier suivant sans casser la build :

1. Nettoyage automatique ciblé : lancer eslint --fix --fix-type problem sur les périmètres les plus bavards (src/lib/components, src/lib/utilsModals.ts, src/routes/(connectivity)) pour éliminer les avertissements "prefer-const" et les cas gérables automatiquement avant d'attaquer la dette métier.【f5800d†L39-L128】
2. Prioriser les avertissements critiques : traiter manuellement les warnings de sécurité/accessibilité (svelte/no-at-html-tags, svelte/valid-compile, a11y-missing-attribute) afin de pouvoir promouvoir ces règles en error dans une prochaine PR et d'éviter les régressions sur les parcours d'affichage.【f5800d†L21-L128】

Concept

La refactorisation ESLint vise à améliorer la qualité du code en configurant des règles strictes, en automatisant les corrections, et en nettoyant les avertissements pour une base de code plus maintenable.

Fonctionnement

Processus étape par étape : mise en place de garde-fous CI, corrections automatiques, durcissement progressif des règles.

Diagrammes

---

e-novatis
Date de dernière mise à jour : date inconnue 3. Planifier la montée en sévérité : une fois les variables inutilisées nettoyées, préparer un changement de configuration ESLint en érigeant @typescript-eslint/no-unused-vars et prefer-const au niveau error, puis mettre à jour le workflow CI pour qu'il échoue en cas de régression.【F:.eslintrc.cjs†L1-L60】【F:.github/workflows/quality.yml†L1-L38】

Cette approche conserve l'esprit "safe-first" : on consomme d'abord les autofix, puis on sécurise les règles sensibles (sécurité, accessibilité) avant de durcir les règles structurelles dans la configuration.