ESLint : repérer les erreurs d'un code JavaScript avant de l'exécuter

ESLint lit le code sans l'exécuter et signale ce qui ressemble à une erreur ou à une mauvaise pratique. Voici sa configuration, ses règles et ses corrections.
3 min de lecture
Believemy logo

Certaines erreurs ne se voient qu'à l'exécution, et parfois seulement sur la page d'un visiteur : une variable mal orthographiée, une promesse jamais attendue, une comparaison douteuse. Le code fonctionne jusqu'au jour où il ne fonctionne plus.

ESLint lit le fichier sans le lancer et signale ces défauts pendant que vous écrivez.


Définition

ESLint est un analyseur statique pour JavaScript : il transforme le code en arbre, applique un jeu de règles et rapporte chaque écart. Les règles sont configurables une par une, ce qui permet à chaque équipe de définir ce qu'elle considère comme une faute.

JAVASCRIPT
// eslint.config.js
import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      'no-console': 'off',
      eqeqeq: 'error',
    },
  },
];

Chaque règle prend l'une des trois valeurs off, warn ou error. Seule la dernière fait échouer la commande, ce qui permet de refuser une fusion sur une erreur tout en tolérant les avertissements.


Ce qu'il attrape vraiment

  • Les variables oubliées : déclarées et jamais utilisées, ou utilisées sans avoir été déclarées.
  • Les promesses lâchées : un await manquant devant un appel asynchrone, signalé par le greffon TypeScript, qui lit les types pour savoir ce qui renvoie une promesse.
  • Le code inatteignable : les lignes placées après un return.
  • Les comparaisons risquées : l'Égalité faible (==) là où l'Égalité stricte (===) s'impose.
  • Les règles d'une bibliothèque : par greffon, comme les contraintes propres aux hooks de React.
Bon à savoir

ESLint ne s'occupe plus de la mise en forme. Les règles d'indentation et de guillemets ont été laissées de côté au profit d'un outil dédié, ce qui évite deux programmes qui se contredisent sur le même fichier.


Le mettre en place sans le subir

La commande npx eslint . analyse le projet, et l'option --fix corrige seule tout ce qui peut l'être sans ambiguïté. L'extension de votre éditeur affiche les mêmes signalements en direct, ce qui reste la boucle la plus utile.

Sur un projet existant, activer d'un coup un jeu de règles complet produit des milliers de signalements que personne ne lira. Mieux vaut partir de la configuration recommandée, la faire passer, puis ajouter les règles une par une en corrigeant au fil de l'eau.


Questions fréquentes

Question

Comment ignorer un signalement précis ?

Un commentaire // eslint-disable-next-line nom-de-la-regle désactive la règle sur la ligne suivante. Nommez toujours la règle concernée, et ajoutez la raison : une désactivation sans explication devient un mystère six mois plus tard.


Question

ESLint remplace-t-il les tests ?

Non, les deux regardent des choses différentes. ESLint vérifie la forme du code sans jamais l'exécuter, un Test unitaire vérifie le résultat obtenu pour des entrées données. Le premier attrape la faute de frappe, le second attrape le calcul faux.


Question

Faut-il l'ajouter dès le premier jour d'un projet ?

Oui, c'est le moment où cela coûte le moins cher : la configuration recommandée suffit, et le projet grandit avec. Les règles de base apprennent aussi beaucoup sur le langage lui-même, chaque signalement pointant un piège réel. Notre formation JavaScript revient sur ces pièges, du typage flottant aux comparaisons trompeuses.

Termes connexes

Découvrez notre glossaire JavaScript

Tous les mots de JavaScript expliqués simplement : mots-clés, objets natifs, méthodes, erreurs et concepts. Définitions claires et exemples qui tournent, pour apprendre et pour se dépanner.

Partager cet article

Tu veux nous aider ? Fais un lien vers cet article sur tes réseaux ou encore mieux : sur ton site, dans un article ou dans ta newsletter.