Les linters ces petits outils qui nous rappellent gentiment que notre code ressemble à un champ de bataille après une soirée trop arrosée. Ou du moins, c’est ce qu’ils devraient faire. Trop souvent, ils se contentent de grogner dans un coin, ignorés comme un TODO oublié depuis 2018. Pourtant, il existe une façon de leur donner du mordant : les faire échouer le build. Oui, vous avez bien lu. On parle bien de transformer une règle de style en un mur infranchissable, un 403 Forbidden pour les mauvaises pratiques.
Pourquoi faire échouer le build ? Parce que les avertissements, c’est pour les faibles
Imaginez un monde où les console.log traînent en production, où les indentations ressemblent à un poème dadaïste, et où les noms de variables sont aussi clairs que x, y et z. Ce monde existe. Il s’appelle « avant que quelqu’un ne configure un linter pour faire échouer le build ».
Les avertissements, c’est bien. Ça fait joli dans la console, ça donne l’impression d’être un développeur consciencieux. Mais soyons honnêtes : si personne ne les lit, autant écrire des haïkus dans un fichier .txt et les stocker dans /dev/null. Un build qui échoue, en revanche, c’est une réalité tangible. C’est le genre de chose qui vous réveille à 3h du matin parce que la CI a décidé que votre dernier commit était une insulte à l’humanité.
La vraie question n’est pas « pourquoi faire échouer le build ? », mais « pourquoi ne pas l’avoir fait plus tôt ? ». Les règles de style ne sont pas là pour décorer votre éditeur. Elles servent à éviter les bugs, à améliorer la lisibilité, et à empêcher votre équipe de vous maudire quand elle devra maintenir votre code. Si une règle est assez importante pour être écrite, elle est assez importante pour être appliquée. Point.
Comment configurer un linter pour qu’il devienne un bourreau (mais un bourreau juste)
Prenons l’exemple d’ESLint, le linter le plus populaire pour JavaScript. Par défaut, il se contente de râler. Pour le transformer en juge impitoyable, il suffit de quelques ajustements. Voici comment procéder, sans fioritures ni jargon inutile.
D’abord, assurez-vous que votre configuration .eslintrc contient les règles que vous voulez appliquer. Par exemple, interdire les console.log en production :
{
"rules": {
"no-console": "error"
}
}
Ensuite, dans votre script de build (ou directement dans la configuration de votre CI), lancez eslint avec l’option --max-warnings 0. Cela signifie : « Si tu trouves ne serait-ce qu’un seul avertissement, fais échouer le build comme si c’était la fin du monde. » Exemple avec un script npm :
"scripts": {
"lint": "eslint . --max-warnings 0"
}
Et voilà. Maintenant, si quelqu’un commet l’erreur de laisser traîner un console.log, le build échouera. Pas de négociation, pas de « je le ferai plus tard ». Juste un beau ERROR rouge qui clignote comme un gyrophare.
Pour les plus paranoïaques (ou les plus sages), vous pouvez aussi intégrer cette vérification dans un hook pre-commit avec Husky. Ainsi, le développeur sera stoppé net avant même d’avoir pu pousser son crime contre l’humanité :
npx husky add .husky/pre-commit "npm run lint"
Résultat : plus de mauvaises surprises en CI, et une équipe qui apprend à respecter les règles par la force. C’est brutal, mais efficace.
Les limites : quand le linter devient un tyran
Bien sûr, tout n’est pas rose dans le monde des linters qui font échouer le build. Il y a des pièges à éviter, sous peine de transformer votre outil en un dictateur capricieux.
Premier écueil : les règles trop strictes. Interdire les any dans un projet TypeScript, c’est bien. Interdire les for au profit des forEach, c’est du dogmatisme. Un linter doit servir le code, pas l’inverse. Si une règle génère plus de frustration que de valeur, elle n’a pas sa place dans votre configuration.
Deuxième piège : l’overhead. Si votre build met 10 minutes à échouer parce que le linter vérifie chaque espace dans chaque fichier, vous avez un problème. Optimisez vos règles, utilisez des outils comme lint-staged pour ne vérifier que les fichiers modifiés, et gardez un œil sur les performances.
Enfin, dernier point : la culture d’équipe. Un linter qui fait échouer le build, c’est bien. Une équipe qui comprend pourquoi c’est bien, c’est mieux. Si vos développeurs voient ça comme une punition plutôt qu’un garde-fou, vous avez raté quelque chose. Expliquez, documentez, et surtout, impliquez l’équipe dans la définition des règles. Un linter imposé par un seul développeur, c’est comme un régime imposé par un nutritionniste sadique : ça ne marche pas.
Conclusion : le linter, ce héros méconnu
Faire échouer le build pour une règle de style, c’est un peu comme mettre une alarme incendie dans une cuisine : ça peut sembler excessif, jusqu’à ce que quelqu’un oublie une casserole sur le feu. Les linters ne sont pas là pour vous embêter, mais pour vous sauver la mise. Alors oui, ça peut faire mal sur le moment. Oui, ça peut sembler tyrannique. Mais au final, c’est une des meilleures façons de garantir que votre code reste propre, maintenable, et surtout, que personne ne doive passer une nuit blanche à débugger un undefined is not a function parce que quelqu’un a oublié un point-virgule.
Alors, la prochaine fois que votre build échoue à cause d’un linter, ne râlez pas. Remerciez-le. Et corrigez votre code.