Skip to content

Résoudre les erreurs ESLint en toute sécurité ​

Cette procédure permet de corriger les erreurs bloquantes sans risquer de modifier le code métier au-delà du nécessaire. Elle s'appuie sur les scripts npm existants et sur la stratégie de refactorisation documentée.

1. Vérifier l'état actuel ​

  1. Assurez-vous d'abord que la configuration SvelteKit est synchronisée, puis lancez l'analyse complète :
    bash
    npm run lint
    Ce script exécute ESLint sur l'ensemble du dépôt en utilisant le cache local pour accélérer les vérifications.【F:package.json†L23-L27】
  2. En CI, npm run lint:ci réutilise la même configuration mais échoue uniquement lorsqu'une erreur (error) est rencontrée, ce qui évite les faux positifs liés aux avertissements déjà tolérés dans la configuration actuelle.【F:package.json†L23-L27】

2. Appliquer les correctifs automatiques sûrs ​

  1. Utilisez systématiquement le script dédié aux autofix limités aux problèmes (--fix-type problem) afin de n'appliquer que les transformations considérées comme sans danger par ESLint :
    bash
    npm run lint:fix:safe
    Ce script corrige les erreurs sans toucher aux règles de style ou d'organisation, ce qui réduit le risque de conflits lors des revues.【F:package.json†L25-L27】
  2. Lorsque vous ciblez un périmètre précis (par exemple src/lib/components ou src/routes/(connectivity)), exécutez la commande en lui passant le chemin concerné pour limiter l'impact :
    bash
    npx eslint src/lib/components --fix --fix-type problem --cache
    Cette approche correspond au plan de nettoyage automatique documenté et évite d'introduire des modifications inutiles ailleurs.【F:docs/technique/refactor-progress.md†L17-L21】

3. Traiter les avertissements restants ​

  1. Priorisez les avertissements liés à la sécurité et à l'accessibilité (par exemple svelte/no-at-html-tags, svelte/valid-compile) avant de modifier la configuration lint afin d'éviter les régressions fonctionnelles.【F:docs/technique/refactor-progress.md†L19-L23】
  2. Lorsque le périmètre est assaini, préparez l'élévation progressive de règles clés (@typescript-eslint/no-unused-vars, prefer-const) au niveau error, puis mettez à jour les workflows CI pour refuser toute régression.【F:docs/technique/refactor-progress.md†L21-L23】

Concept ​

Ce playbook fournit une procédure sécurisée pour résoudre les erreurs ESLint sans risquer de modifier le code métier, en s'appuyant sur des scripts automatiques et une stratégie progressive.

Fonctionnement ​

Étapes : vérifier l'état, appliquer les correctifs automatiques sûrs, traiter les avertissements restants, et préparer l'élévation des règles.

Diagrammes ​


e-novatis
Date de dernière mise à jour : date inconnue

4. Valider avant merge ​

  1. Relancez npm run lint et npm run typecheck pour vérifier que les correctifs n'ont rien cassé et qu'aucune nouvelle erreur n'apparaît.【F:package.json†L20-L27】
  2. Ajoutez, si nécessaire, des tests ciblés (npm run test) afin de sécuriser les parcours critiques lorsque la correction touche au comportement applicatif.【F:package.json†L20-L31】

En suivant ces étapes, vous garantissez que les corrections lint restent maîtrisées et cohérentes avec la stratégie de durcissement progressif déjà engagée par l'équipe.【F:docs/technique/refactor-progress.md†L17-L23】