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.
// 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.
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
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.
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.
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.