Comprendre ce que fait un linter
Un linter est un outil d'analyse statique qui examine votre code source sans l'exécuter. Il détecte les constructions suspectes, les erreurs potentielles, les violations de conventions de style et les patterns dangereux. ESLint pour JavaScript, Pylint pour Python, RuboCop pour Ruby : chaque langage a son analyseur de référence. Contrairement à ce que pensent certains développeurs débutants, le linter ne se contente pas de traquer les espaces manquants ou les guillemets mal assortis. Il prévient des bugs réels : variables jamais utilisées qui alourdissent le code, fonctions trop complexes qui deviennent impossibles à maintenir, ou encore passages qui échoueront silencieusement en production.
La distinction entre une erreur et un avertissement est essentielle. Une erreur bloquera votre build ou votre commit selon la configuration ; un avertissement signale une pratique déconseillée sans empêcher l'exécution. Savoir lire ces signaux est la première compétence à acquérir pour tirer parti de ces outils sans frustration.
Les erreurs ESLint les plus fréquentes
ESLint est le linter JavaScript le plus déployé. Ses règles par défaut couvrent plusieurs centaines de cas, mais certaines erreurs reviennent systématiquement dans les projets.
La variable inutilisée (no-unused-vars)
Cette règle signale toute variable déclarée mais jamais référencée dans le reste du fichier. La cause est souvent un refactoring incomplet : une fonction a été modifiée, mais l'ancien paramètre ou la variable temporaire est resté. La correction consiste à supprimer la variable, ou à la préfixer d'un underscore si elle est intentionnellement non utilisée (convention acceptée par ESLint avec l'option argsIgnorePattern). Dans les projets TypeScript, cette règle est remplacée par @typescript-eslint/no-unused-vars qui offre une détection plus fine, notamment pour les types et interfaces.
Le symbole non défini (no-undef)
ESLint ne connaît que les variables déclarées dans le fichier courant. Si vous utilisez process (Node.js) ou window (navigateur), vous obtenez immédiatement une erreur no-undef. La solution est de déclarer l'environnement dans votre configuration ESLint : env: { node: true } ou env: { browser: true }. C'est un oubli courant sur les nouveaux projets ou lors de la migration d'un projet JavaScript vers un environnement particulier.
Les incohérences de style (semi, quotes, indent)
Ces règles provoquent souvent les premiers cris de frustration chez les développeurs : « Pourquoi mon éditeur me force-t-il à mettre des guillemets simples ? » La réponse est simple : votre équipe (ou le template que vous avez cloné) a choisi des conventions. Inutile de lutter contre. Si vous préférez les guillemets doubles et les points-virgules, modifiez ces règles dans votre .eslintrc ou appliquez Prettier qui prend en charge le formatage automatique (nous y reviendrons).
Les conflits entre Prettier et ESLint
C'est sans doute la source la plus fréquente de confusion. Prettier formate le code (espaces, retours à la ligne, guillemets) tandis qu'ESLint vérifie la logique et les conventions. Le problème survient quand les deux outils appliquent des règles contradictoires : Prettier ajoute des virgules trailing qu'ESLint interdit, ou Prettier impose des guillemets simples quand ESLint exige des doubles. Le résultat est un conflit permanent où chaque sauvegarde provoque une cascade d'erreurs.
La solution standard consiste à installer eslint-config-prettier (pour désactiver toutes les règles ESLint qui entrent en conflit avec Prettier) et éventuellement eslint-plugin-prettier (pour exécuter Prettier comme une règle ESLint). La configuration typique devient alors : ESLint gère la qualité du code, Prettier gère le formatage. Les deux coexistent sans se marcher sur les pieds.
Pylint et Flake8 : les linters Python
Dans l'écosystème Python, deux outils dominent. Pylint est le plus complet : il vérifie le style (PEP 8), les erreurs potentielles, la complexité des fonctions, et même la convention de nommage. Flake8 est plus léger et plus rapide, combinant PyFlakes, pycodestyle et McCabe. Beaucoup d'équipes les utilisent ensemble : Flake8 pour la vérification rapide en pre-commit, Pylint pour une analyse approfondie dans la CI.
Les erreurs les plus communes sous Pylint incluent C0301 (ligne trop longue, au-delà de 80 ou 100 caractères selon la configuration) et R0913 (trop de paramètres dans une fonction). La tentation est d'ajouter # pylint: disable=... partout. Résistez-y : chaque désactivation est une opportunité de refactoring manquée. Si une fonction a sept paramètres, c'est peut-être le signe qu'elle mérite d'être décomposée.
Automatiser la correction pour ne plus y penser
Le meilleur dépannage des erreurs de linter est celui qu'on n'a pas à faire manuellement. Voici comment automatiser le processus à chaque étape du cycle de développement.
Dans l'éditeur : corrections à la volée
VS Code, JetBrains et Neovim intègrent tous des extensions ESLint, Pylint ou Prettier qui surlignent les erreurs en direct et proposent une correction automatique. Activez l'option « format on save » dans votre éditeur : à chaque sauvegarde, Prettier reformate le fichier et ESLint applique les corrections automatiques (fix) disponibles. Une grande partie des erreurs disparaît avant même que vous ayez changé de fichier.
Dans le repository : pre-commit hooks
L'outil pre-commit (à ne pas confondre avec le mécanisme Git du même nom) permet d'exécuter les linters avant chaque commit. Si une erreur est détectée, le commit est bloqué et le développeur doit corriger avant de réessayer. La configuration est simple : un fichier .pre-commit-config.yaml à la racine du projet, qui liste les hooks (eslint, prettier, pylint, flake8, etc.) et leurs versions. Avantage : plus personne ne peut pousser du code qui ne passe pas les linters, même en oubliant de les lancer localement.
Dans la CI : bouclier de dernière ligne
Même avec les pre-commit hooks, un développeur peut forcer un commit avec git commit --no-verify. La CI est la dernière barrière. Ajoutez une étape de linting dans votre pipeline GitHub Actions, GitLab CI ou Jenkins. Si elle échoue, la pull request ne peut pas être fusionnée. Cette redondance est volontaire : elle garantit que le code en production respecte les standards de l'équipe, indépendamment des contournements individuels.
Questions fréquentes
Pourquoi mon linter signale-t-il des erreurs dans des fichiers que je n'ai pas modifiés ?
C'est normal si la configuration du linter a changé récemment (nouvelle règle, nouvelle version), ou si vous avez changé d'environnement. Lancez le linting sur l'ensemble du projet une fois pour identifier toutes les erreurs, puis corrigez-les progressivement ou ajoutez un commit dédié au nettoyage.
Dois-je corriger toutes les erreurs de linter ?
Non. Certaines règles sont des avertissements de style ou des recommandations. Concentrez-vous sur les erreurs (niveau error dans ESLint, note inférieure à un seuil dans Pylint). Les avertissements peuvent être traités lors de sessions de refactoring dédiées.
Comment ignorer une règle spécifique sur une ligne précise ?
Utilisez un commentaire d'ignor : // eslint-disable-next-line no-console en JavaScript, # pylint: disable=unused-argument en Python. Faites-le avec parcimonie et documentez pourquoi dans le commentaire.
Faut-il un linter pour chaque langage d'un projet ?
Oui, idéalement. Un projet moderne peut mêler JavaScript, TypeScript, CSS, Python et YAML. Chaque langage a son outil : ESLint (JS/TS), Stylelint (CSS), Pylint (Python), yamllint (YAML). L'outil pre-commit unifie leur exécution.