ESLint

Qu’est-ce qu’ESLint ?

ESLint est un linter pluggable pour JavaScript et TypeScript. Il analyse votre code pour le transformer en arbre de syntaxe, lui applique un ensemble de règles et signale les problèmes. Ces règles vont de la détection de bugs réels — variables inutilisées, await manquant, égalités non sécurisées — aux conventions que votre équipe souhaite imposer.

La valeur ajoutée est cumulative. Chaque règle permet de détecter une catégorie d’erreurs une fois pour toutes, partout, au lieu de compter sur les relecteurs pour les remarquer. De nombreuses règles proposent également une correction automatique, sehingga eslint --fix nettoie une quantité surprenante de code automatiquement. ESLint est l’un des outils les plus efficaces pour optimiser un projet JavaScript.

Flat config

ESLint utilise le flat config : un fichier qui exporte un tableau d’objets de configuration. Ce format remplace l’ancien format .eslintrc par des imports explicites et une composition prévisible.

// eslint.config.js
import js from "@eslint/js";
import tseslint from "typescript-eslint";

export default tseslint.config(
  { ignores: ["dist", "coverage", "**/*.generated.*"] },
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    files: ["**/*.ts", "**/*.tsx"],
    rules: {
      "@typescript-eslint/no-floating-promises": "error",
    },
  },
);

Chaque objet peut spécifier les fichiers auxquels il s’applique, les plugins qu’il enregistre et les règles qu’il définit. Les objets situés plus bas dans le tableau écrasent les précédents, le tableau se lit donc de haut en bas, comme une cascade.

Règles et sévérité

Chaque règle possède un niveau de sévérité : "off", "warn" ou "error".

// rules.js
export default [
  {
    rules: {
      eqeqeq: "error",              // require ===
      "no-unused-vars": "warn",
      "no-console": ["warn", { allow: ["warn", "error"] }],
    },
  },
];

Certaines règles acceptent des options, comme c’est le cas pour no-console ici. error fait échouer la CI ; warn signale l’erreur sans faire échouer le build. Utilisez warn pour les règles que vous déployez progressivement et error pour tout ce qui doit bloquer une fusion (merge).

Plugins et presets

Les plugins ajoutent des règles pour des écosystèmes spécifiques, et les presets regroupent un ensemble sélectionné de ces règles.

// react.js
import react from "eslint-plugin-react";
import reactHooks from "eslint-plugin-react-hooks";

export default [
  react.configs.flat.recommended,
  reactHooks.configs["recommended-latest"],
];

Les plugins courants couvrent React, Vue, TypeScript, les imports, les bibliothèques de test et l’accessibilité. En commençant par eslint:recommended accompagné d’un preset de framework, vous obtenez 90 % de la valeur avec presque aucune configuration. N’ajoutez des règles individuelles que si vous en avez une raison précise.

Linting basé sur les types

typescript-eslint peut utiliser le vérificateur de types de TypeScript pour des règles que l’analyse syntaxique simple ne peut pas gérer.

// type-aware.js
export default tseslint.config({
  languageOptions: {
    parserOptions: {
      projectService: true,
      tsconfigRootDir: import.meta.dirname,
    },
  },
  rules: {
    "@typescript-eslint/no-floating-promises": "error",
    "@typescript-eslint/no-misused-promises": "error",
  },
});

Des règles comme no-floating-promises permettent de détecter des bugs réellement difficiles à repérer à la lecture : une promesse qui n’est jamais attendue avec await. Le linting basé sur les types est plus lent car il exécute le vérificateur de types ; c’est pourquoi de nombreux projets l’activent pour le code source mais l’ignorent pour les tests et les fichiers de configuration.

Correction et désactivation

De nombreuses règles peuvent être corrigées automatiquement ; lancez donc le fixer avant de consulter le résultat.

npx eslint . --fix

Lorsque vous devez réellement déroger à une règle, désactivez-la de manière ciblée et expliquez pourquoi.

// targeted.js
// eslint-disable-next-line no-console -- intentional debug log
console.log("payment flow", payload);

L’utilisation d’un /* eslint-disable */ global en haut d’un fichier désactive tout, y compris les règles qui auraient pu détecter de véritables bugs. Privilégiez une désactivation sur une seule ligne accompagnée d’une justification, et ajustez la configuration si une règle entre en conflit avec vos standards.

Éditeurs et CI

Installez l’extension ESLint pour votre éditeur et activez l’option “fix-on-save”. Vous recevrez un retour en temps réel pendant la saisie et les corrections sécurisées seront appliquées immédiatement, transformant ainsi le linting en une partie intégrante du flux de développement plutôt qu’en une corvée. Dans votre CI, exécutez ESLint comme une étape distincte afin que les échecs soient clairs et rapides, et mettez les résultats en cache lorsque c’est possible.

Le rôle d’ESLint

ESLint s’occupe de la qualité du code ; Prettier s’occupe du formatage. La configuration standard consiste à laisser Prettier gérer le style et à désactiver les règles ESLint qui entrent en conflit, souvent via une configuration partagée. Ensemble, ils permettent aux relecteurs de discuter de la conception plutôt que des espaces et des points-virgules.

Bonnes pratiques

• Commencez par eslint:recommended et un preset de framework, puis ajoutez des règles de manière réfléchie.
• Utilisez la flat config avec des imports explicites et une liste d’ignores claire.
• Laissez Prettier gérer le formatage et désactivez les règles ESLint conflictuelles.
• Exécutez --fix avant de trier les problèmes restants.
• Activez les règles type-aware pour les fichiers sources.
• Désactivez les règles de façon ciblée, avec un commentaire expliquant pourquoi.
• Lancez le linting dans l’éditeur, via un hook de pre-commit et dans la CI.

Erreurs courantes

• Linter dist, le code généré et les dépendances.
• Désactiver massivement des règles au lieu de corriger la cause racine.
• Activer toutes les règles d’un coup et se laisser submerger par le bruit.
• Dupliquer des règles de formatage déjà gérées par Prettier.
• Exécuter le linting basé sur les types sur l’ensemble du repo, ce qui ralentit le processus.
• Considérer les warnings comme inoffensifs jusqu’à ce qu’ils s’accumulent.

Et après ?

ESLint est le garant de la qualité de votre codebase. Associez-le à Prettier pour le formatage, renforcez le typage avec TypeScript, et intégrez-le au build Vite ainsi qu’à votre pipeline CI. Ensuite, activez une nouvelle règle et corrigez chaque occurrence : c’est une petite habitude qui apporte un bénéfice considérable.