Tactiques ESLint pour le code legacy
Comment améliorer votre code avec ESLint quand il y a des centaines d’erreurs ?
Cet article présente quatre tactiques pour lutter contre la dette technique via ESLint. Ces conseils sont particulièrement utiles si vous venez d’ajouter le linter sur un projet existant.
1. Adapter les règles
Tout d’abord, inutile de mettre en place de nombreuses règles strictes sur une base de code qui a déjà vécu depuis des mois, voire des années. J’ai par exemple vu une tentative de mettre en place la célèbre configuration Airbnb, générant de nombreuses erreurs et rendant ainsi la tâche quasi impossible. En effet, voir des milliers d’erreurs et de warnings sur son projet a un côté déprimant, et il est facile de se perdre dans des corrections mineures.
Il faut plutôt commencer avec des règles moins nombreuses, mais impactant la qualité de code. Par exemple les règles eslint:recommended
{
"extends": "eslint:recommended"
}Plus généralement, il ne faut pas hésiter à configurer ou désactiver des règles individuellement pour coller aux conventions et règles de codage de votre équipe.
2. Intégrer ESLint à votre CI
Il est indispensable d’ajouter ESLint au plus tôt dans votre Intégration Continue. À titre informatif tout d’abord via une étape de la CI qui peut échouer sans stopper vos pipelines. Si vous utilisez Sonar, c’est une bonne idée d’y ajouter le reporting d’ESLint.
Ensuite, vous pourrez tolérer un nombre de plus en plus bas d’erreurs ou warnings. Une alternative est de ne linter que les nouveaux fichiers ou les fichiers modifiés. Voici un script volé sur StackOverflow qui fait ça :
eslint --fix $(git diff --name-only origin/develop '**/*.js' | xargs)3. Règle du boy scout et boucle de feedback
Nous allons pouvoir mettre en application la règle du boy scout qui consiste à laisser le camp de base plus propre que quand on est arrivé. Cette pratique a plusieurs avantages : résorber la dette technique petit à petit, mais aussi donner un sentiment d’ownership plus grand.
Après votre passage, laissez le code dans un meilleur état que celui dans lequel vous l’avez trouvé
Pour pouvoir appliquer cette règle, il faut raccourcir la boucle de feedback en évitant les allers-retours entre votre IDE et la CI. Il est donc indispensable d’installer et de configurer le plugin nécessaire pour votre éditeur ou IDE préféré. J’utilise personnellement l’extension ESLint pour VS Code, sans oublier de l’activer comme formateur.
F8 vous emmène au prochain warning ou erreur
Alt + Shift + F formate automatiquement avec les règles ESLint, idéal si vous y avez mis Prettier
Ctrl + ; permet des actions automatiques ou bien de visualiser la documentation de la règle incriminée
On se facilite la vie en ayant toutes ces informations claires sous les yeux ou à portée de clavier.
4. Fixer par erreur, par fichier
Avant tout, la première chose à faire est de vérifier s’il y a des erreurs fixables automatiquement via l’option --fix d’ESLint. Ce serait dommage de passer à côté.
Pour identifier les erreurs les plus courantes, nous allons utiliser le package npm eslint-stats. C’est un outil qui permet de regrouper les résultats par erreur/warning. Comme souvent, une erreur est corrigeable assez facilement et toujours de la même façon. Il est donc plus efficace de procéder par erreurs plutôt que par fichiers en activant les règles une par une.
eslint-nibble est similaire à eslint-stats mais permet en plus de sélectionner une règle pour voir les erreurs correspondantes et les traiter.
npm install --no-save eslint-nibble
npx eslint-nibble .Une façon de cibler par fichier est de passer par Git pour identifier les fichiers sur lesquels les développeurs sont les plus actifs. Pour ça nous allons utiliser Git extras pour identifier les fichiers commité 3 fois ou plus le mois dernier.
git effort --above 3 -- --since='last month'Conclusion
Nous avons vu ensemble comment rendre possible une tache qui paraît dantesque. ESLint est un outil formidable qui permet de repérer et de traiter des erreurs courantes. Il permet de mettre en place de bonnes pratiques de codage et d’automatiser une partie de la relecture de code.
Une fois les erreurs ESLint traitées, on peut s’attaquer à des problèmes plus haut niveau !
