ESLint : comment améliorer la qualité et la fiabilité de votre code JavaScript

Un code JavaScript peut fonctionner aujourd’hui et devenir difficile à maintenir demain. Une variable mal nommée, une promesse oubliée, une condition trop complexe ou une dépendance utilisée de travers suffisent parfois à créer un bug discret. Le problème n’est pas toujours visible dans le navigateur : il attend souvent le prochain refactoring, la prochaine mise en production ou le prochain développeur qui ouvrira le fichier.

ESLint agit comme un filet de sécurité. Cet outil analyse votre code JavaScript, repère les erreurs potentielles et signale les pratiques qui risquent de compliquer la vie de l’équipe. Il ne remplace ni les tests ni la relecture humaine, mais il automatise une partie essentielle du contrôle qualité.

Dans cet article, voyons comment intégrer ESLint dans un projet, choisir des règles pertinentes et transformer cet outil parfois perçu comme un simple “policier du code” en véritable assistant de développement.

ESLint, à quoi ça sert exactement ?

ESLint est un analyseur statique pour JavaScript et les technologies de son écosystème. Il examine le code sans l’exécuter afin d’identifier des erreurs, des incohérences de style et des constructions potentiellement dangereuses.

Son intérêt repose sur un principe simple : détecter les problèmes le plus tôt possible. Une erreur repérée dans l’éditeur coûte quelques secondes à corriger. La même erreur découverte après une mise en production peut nécessiter une recherche dans les logs, une correction urgente et quelques cafés supplémentaires.

ESLint peut notamment signaler :

• des variables déclarées mais jamais utilisées ;
• des fonctions qui ne respectent pas certaines conventions ;
• des égalités faibles comme == lorsqu’elles sont interdites par le projet ;
• des blocs de code trop complexes ou difficiles à lire ;
• des promesses mal gérées ;
• des imports inutilisés ou mal organisés ;
• des pratiques incompatibles avec un framework comme React ou Vue.

L’outil fonctionne avec un système de règles. Chaque règle peut être activée, désactivée ou configurée selon le contexte du projet. Vous pouvez donc l’adapter à une application React, une API Node.js, un site vitrine ou une bibliothèque distribuée en npm.

Pourquoi utiliser un linter dans un projet JavaScript ?

La première valeur d’ESLint est la cohérence. Dans une équipe, chacun possède ses habitudes : guillemets simples ou doubles, point-virgule ou non, fonctions fléchées partout ou seulement lorsque c’est pertinent. Ces préférences sont légitimes, mais elles deviennent bruyantes lorsqu’elles varient d’un fichier à l’autre.

Un ensemble de règles partagé permet de consacrer les revues de code aux sujets importants. Au lieu de commenter la présence d’un espace ou d’une variable inutilisée, les développeurs peuvent discuter de l’architecture, de la performance ou de l’expérience utilisateur.

ESLint contribue aussi à réduire certains bugs classiques. Une règle peut, par exemple, vous alerter lorsqu’une variable est redéclarée, lorsqu’une promesse n’est pas attendue ou lorsqu’une branche de code est impossible à atteindre. Ce ne sont pas des garanties absolues, mais ce sont autant de pièges évités avant l’exécution.

Enfin, ESLint documente indirectement les conventions du projet. Le fichier de configuration devient une sorte de guide technique exécutable. Il explique ce qui est encouragé, toléré ou interdit, sans demander à chaque nouveau membre de l’équipe de mémoriser une longue liste de règles.

Installer ESLint dans un projet

Dans un projet Node.js existant, l’installation se fait généralement comme dépendance de développement :

npm install --save-dev eslint

Avec pnpm, la commande devient :

pnpm add --save-dev eslint

Les versions récentes d’ESLint utilisent une configuration dite “flat config”, généralement placée dans un fichier eslint.config.js. Cette approche remplace progressivement les anciens fichiers .eslintrc et clarifie la manière dont les configurations sont composées.

Une configuration minimale peut ressembler à ceci :

import js from "@eslint/js";export default [  js.configs.recommended,  {    rules: {      "no-console": "warn",      "prefer-const": "error"    }  }];

La configuration recommandée active un ensemble de règles utiles pour détecter les erreurs courantes. Vous pouvez ensuite ajouter vos propres choix. Ici, l’utilisation de console génère un avertissement, tandis qu’une variable qui pourrait être déclarée avec const est considérée comme une erreur.

Pour lancer l’analyse, ajoutez un script dans package.json :

{  "scripts": {    "lint": "eslint ."  }}

La commande suivante analysera les fichiers compatibles du projet :

npm run lint

Un conseil pratique : installez ESLint dès le début d’un projet. Ajouter les règles après plusieurs mois de développement peut produire une avalanche de messages. Et personne n’aime découvrir 1 247 erreurs juste après avoir lancé une commande censée “améliorer la qualité” du code.

Choisir les bonnes règles sans ralentir l’équipe

ESLint propose beaucoup de règles, mais toutes ne doivent pas être activées immédiatement. Une configuration trop stricte peut transformer chaque sauvegarde en parcours d’obstacles. À l’inverse, un ensemble trop permissif donnera une fausse impression de sécurité.

Commencez par les problèmes qui ont un impact concret sur la fiabilité :

• no-unused-vars pour repérer les variables et paramètres inutilisés ;
• no-undef pour détecter les variables non déclarées ;
• no-unreachable pour identifier le code impossible à atteindre ;
• no-constant-condition pour éviter certaines conditions toujours vraies ou fausses ;
• eqeqeq pour privilégier une comparaison stricte ;
• no-duplicate-imports pour limiter les imports redondants ;
• prefer-const pour rendre l’intention du code plus claire.

Les règles de style, comme la longueur maximale d’une ligne ou le type de guillemets, sont utiles, mais elles ne doivent pas prendre le dessus sur les enjeux fonctionnels. Le but n’est pas d’obtenir un code décoré au millimètre. Le but est de rendre le code prévisible, lisible et robuste.

Pour le formatage automatique, beaucoup d’équipes associent ESLint à Prettier. ESLint se concentre alors sur la qualité et les erreurs potentielles, tandis que Prettier gère la mise en forme. Cette séparation évite de multiplier les règles de style dans ESLint.

Adapter ESLint à JavaScript moderne

JavaScript ne se limite plus à quelques fichiers inclus dans une page HTML. Un projet actuel peut utiliser les modules ES, TypeScript, React, Vue, Node.js, des fonctions asynchrones et un bundler. ESLint doit donc connaître l’environnement dans lequel le code s’exécute.

Pour un projet Node.js, certaines règles ou variables globales peuvent être spécifiques au serveur. Pour un projet destiné au navigateur, les objets comme window ou document doivent être reconnus. Dans les deux cas, une configuration adaptée évite les faux positifs.

Dans un projet React, le plugin officiel permet de détecter des erreurs liées aux composants et aux hooks. L’installation peut se faire avec :

npm install --save-dev eslint-plugin-react-hooks

Une règle particulièrement utile concerne les hooks. Leur ordre d’appel doit rester stable entre les rendus. Une mauvaise utilisation de useEffect ou useMemo peut produire des comportements difficiles à comprendre. Un plugin spécialisé détecte plusieurs de ces problèmes avant même que l’application soit ouverte dans le navigateur.

Pour TypeScript, ESLint peut être associé à typescript-eslint. Cette intégration permet d’analyser la syntaxe TypeScript et d’appliquer des règles adaptées aux types, aux interfaces et aux annotations. Il est important de ne pas demander à ESLint de remplacer le compilateur TypeScript : les deux outils se complètent.

Corriger automatiquement les problèmes

ESLint ne se contente pas de dresser une liste de reproches. Certaines règles peuvent être corrigées automatiquement avec l’option --fix :

npx eslint . --fix

Cette commande peut ajuster des espaces, supprimer certains imports inutiles, modifier des guillemets ou appliquer des transformations sans risque. Elle fait gagner du temps, notamment avant une revue de code.

Il faut néanmoins garder un œil humain sur les modifications. Une correction automatique peut modifier la forme du code sans comprendre l’intention métier. Avant de valider les changements, consultez toujours le diff généré par Git.

Dans l’éditeur, l’extension ESLint pour Visual Studio Code affiche les erreurs directement dans les fichiers. Les problèmes apparaissent au moment où vous écrivez le code, et non quelques minutes plus tard dans le terminal. Cette boucle de retour rapide rend l’outil beaucoup plus naturel à utiliser.

Une configuration efficace combine généralement trois niveaux :

• des messages visibles dans l’éditeur pendant le développement ;
• un script lint lancé avant chaque demande de fusion ;
• un contrôle automatique dans la chaîne d’intégration continue.

Intégrer ESLint dans Git et la CI

Un linter est réellement utile lorsqu’il est exécuté régulièrement. Si la vérification dépend uniquement de la motivation de chaque développeur, elle finira par être oubliée un vendredi après-midi, juste avant une mise en production.

Vous pouvez lancer ESLint dans votre pipeline CI, par exemple avec GitHub Actions :

name: Qualityon:  pull_request:jobs:  lint:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: actions/setup-node@v4        with:          node-version: 20      - run: npm ci      - run: npm run lint

Chaque demande de fusion est alors vérifiée automatiquement. Si une règle critique échoue, la fusion peut être bloquée. Ce mécanisme garantit que le code accepté dans la branche principale respecte le niveau de qualité défini par l’équipe.

Pour les grands projets, il peut être intéressant de ne vérifier que les fichiers modifiés grâce à des outils comme lint-staged et Husky. Le contrôle reste rapide tout en intervenant avant le commit.

Gérer les erreurs existantes sans abandonner

Lorsqu’ESLint est ajouté à une application ancienne, le premier rapport peut être impressionnant. La tentation est alors de désactiver la moitié des règles. Une meilleure stratégie consiste à avancer progressivement.

Commencez par corriger les erreurs qui peuvent provoquer un bug : variables inconnues, promesses mal utilisées, imports incohérents ou branches impossibles. Ensuite, traitez les avertissements et les règles de style.

Vous pouvez aussi limiter temporairement l’analyse à certains répertoires ou utiliser des commentaires ciblés :

// eslint-disable-next-line no-consoleconsole.log("Message utile pour le diagnostic");

Cette exception doit rester exceptionnelle et documentée. Ajouter un eslint-disable sur un fichier entier revient souvent à coller un morceau de ruban adhésif sur le voyant moteur. Le bruit disparaît, mais le problème est toujours là.

Pour éviter l’accumulation de dette technique, traitez les nouvelles erreurs comme bloquantes et planifiez la correction des anciennes par petites étapes. La qualité progresse ainsi sans immobiliser tout le projet.

Les limites d’ESLint à garder en tête

ESLint analyse la structure et certaines pratiques du code, mais il ne comprend pas toujours le métier. Il ne saura pas forcément qu’un prix négatif est impossible, qu’un formulaire doit respecter une règle juridique ou qu’un appel réseau doit être retenté dans un cas précis.

Il ne remplace pas non plus les tests unitaires, les tests d’intégration, l’analyse de sécurité ou la revue de code. Un fichier peut respecter toutes les règles ESLint et contenir malgré tout une logique fonctionnelle incorrecte.

L’outil doit donc s’inscrire dans une démarche plus large : conventions partagées, tests automatisés, documentation utile et échanges réguliers entre développeurs. ESLint s’occupe d’une partie du terrain. À l’équipe de jouer le reste du match.

Une méthode simple pour démarrer

Pour intégrer ESLint sans complexifier votre quotidien, vous pouvez suivre une progression en quelques étapes :

• installez ESLint comme dépendance de développement ;
• activez la configuration recommandée ;
• ajoutez uniquement les règles adaptées à votre projet ;
• configurez un script lint dans package.json ;
• activez les corrections automatiques sans valider aveuglément les changements ;
• intégrez l’analyse dans votre éditeur et votre CI ;
• corrigez progressivement les erreurs héritées ;
• réévaluez la configuration lorsque le projet ou l’équipe évolue.

La qualité du code ne naît pas d’une règle magique. Elle vient d’habitudes régulières et de garde-fous bien placés. En automatisant les vérifications répétitives, ESLint permet aux développeurs de se concentrer sur ce qui demande réellement du jugement : concevoir une fonctionnalité utile, maintenir une architecture saine et offrir une expérience fiable aux utilisateurs.