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】