Un linter, c’est un outil qui permet d’analyser du code pour en faire ressortir les erreurs ou incohérences en fonction de règles prédéfinies. Très largement intégrée aux projets aujourd’hui, sa version destinée au JavaScript, ESLint, est pourtant rarement utilisée à son plein potentiel.
À travers l’importance d’avoir un code propre et unifié pour un développeur freelance, nous allons voir en quoi ESLint est un outil essentiel au développeur JavaScript, et comment le configurer.
Suivez le guide !
L’importance d’avoir un code JavaScript de qualité
Comme on l’a dit, un linter est un outil permettant d’analyser du code pour y mettre en évidence les erreurs (du langage en lui-même ou des règles subjectives définies en interne), et donc d’avoir un code de qualité. Mais, avant tout, en quoi c’est important d’avoir un code de qualité ?
En dehors d’éviter les erreurs de runtime, avoir un code d’une bonne qualité syntaxique a plusieurs intérêts :
- Une bonne lisibilité du code, que ça soit par vous-même, plus tard, ou par vos collègues ;
- Une meilleure maintenabilité, notamment grâce à cette lisibilité améliorée ;
- Une meilleure gestion des ressources et performances, et donc un produit plus qualitatif.
Pour avoir plus de détails sur les notions plus génériques de propreté du code, vous pouvez aller lire notre article sur les bonnes pratiques de codage, juste ici.
L’ESLint pour maintenir du JavaScript propre
Maintenant qu’on a vu l’intérêt d’avoir un code propre, notamment grâce à un linter, voyons plus en détails ce qu’est ESLint.
ESLint est donc le code checker JavaScript le plus utilisé de tous. Né en 2013 des mains de Nicholas Zakas, le plugin compte aujourd’hui plus de 14 millions de téléchargements… par semaine !
Et, comme nous le verrons, s’il est tant utilisé, c’est pour de bonnes raisons. Ce module est en effet un vrai soutien pour tout développeur JavaScript, une aide qui intervient en permanence.
Le but d’ESLint
Si ce linter est aussi utilisé parmi les développeurs JavaScript, c’est pour les multiples façons dont il aide le développeur :
- Il permet d’identifier les bugs à l’écriture plutôt qu’au runtime, avec donc un gain de temps ;
- Il montre directement où sont les erreurs de syntaxes, ce qui évite de passer du temps sur des erreurs d’inattention (comme un « = » à la place d’un « == » dans un if) ;
- ESLint permet aussi d’uniformiser la codebase, surtout si plusieurs développeurs travaillent sur le même projet (c’est-à-dire avoir des règles syntaxiques uniques).
C’est donc un petit plugin, mais une grande aide pour ceux qui utilisent du JavaScript au quotidien.
Les limites d’ESLint
Peut-on parler de limites lorsqu’il s’agit de linter ? Pas vraiment. En fait, il ne s’agit ni plus ni moins que d’un plugin configurable, comme on le verra, qui aide le développeur.
Cependant, ESLint a indirectement des défauts, qui sont plus liés à son utilisation qu’au plugin lui-même.
Par exemple, il « formate » un développeur à coder d’une certaine façon, voulue par son lead dev ou CTO. Cela peut aller loin, on ne parle plus seulement du saut de ligne à la fin d’une condition, mais aussi de l’absence ou de l’obligation du point-virgule en fin de ligne. En soi, rien de gênant, sauf que si le développeur change de mission et tombe sur un CTO qui impose les règles opposées, c’est perturbant – et ça arrive.
Aussi, certains CTO, pour être sûrs que leurs développeurs respectent les guidelines, ajoutent des conditions aux commits Git, le respect des règles ESLint étant l’une d’entre elles. On peut se poser la question de l’utilité de ce genre de pratiques.
Installer et setter votre ESLint
Maintenant qu’on en a fini avec l’introduction d’ESLint, on va passer à la phase d’installation et de mise en place de cet outil.
Installation
Il y a plusieurs façon d’installer et d’exécuter ESLint.
En ligne de commande
La première façon d’installer ce linter est donc en ligne de commande. Il suffit de taper la ligne suivante dans votre terminal pour installer ESLint localement dans votre projet :
$ npm install eslint --save-dev
Ensuite, le package, pour fonctionner, a besoin d’un fichier de configuration, qui va dicter les règles au linter, règles qu’il utilisera pour vérifier le code. Vous pouvez créer directement un fichier .eslintrc à la racine, ou utiliser la commande prévue à cet effet :
eslint --init
Nous reviendrons sur la configuration de ce fichier plus tard. Pour valider votre code source grâce à ESLint, il suffit de lancer la commande suivante :
eslint
Suivi du nom du ou des fichiers/dossiers que vous voulez valider.
Pour inclure directement une commande eslint à votre projet, vous pouvez l’ajouter dans les scripts définis dans le fichier package.json. Par exemple :
{
"scripts": {
"lint": "eslint ."
}
}
Exécutera ESLint sur l’ensemble de votre projet au lancement de la commande ‘run lint’.
Dans votre IDE
La deuxième façon d’installer ESLint, c’est directement dans votre IDE, via un plugin. On retrouve sur VSCode, par exemple, un plugin ESLint qui compte plus de 16 millions d’installations. Il existe aussi évidemment d’autres linter, par exemple pour TypeScript.
Cela permet d’afficher les warnings et erreurs en temps réel dans votre éditeur, sans avoir besoin de lancer une commande spécifique.
Personnaliser votre ESLint
Comme on l’a déjà dit, vous pouvez personnaliser les règles qu’applique votre ESLint sur votre projet. C’est ce qui permet, en plus de vérifier qu’un code n’ait pas d’erreur, de définir des règles syntaxiques propres à une équipe ou une entreprise.
Les règles ESLint se définissent dans le fichier qu’on a créé à la racine du projet à l’étape de l’installation, le .eslintrc.
Voici un exemple de ce à quoi peut ressembler un fichier de configuration pour ESLint.
module.exports = {
root: true,
env: {
node: true
},
'extends': [
'plugin:vue/vue3-essential',
'eslint:recommended',
'@vue/typescript/recommended'
],
parserOptions: {
ecmaVersion: 2020
},
rules: {
'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off'
}
}
Les règles personnalisées sont définies dans l’objet ‘rules’ qu’on voit en bas de cet exemple. Pour chaque règle, il existe 3 niveaux de paramétrage :
- « off » ou 0 permet de désactiver une règle ;
- « warn » ou 1 donne un avertissement ;
- « error » ou 2 donne une erreur bloquante, soulignée en rouge dans votre IDE.
Les règles peuvent concerner à peu près tout et n’importe quoi, par exemple :
- La règle ‘eqeqeq‘, oblige l’utilisation des ‘===’ et ‘!==’ à la place des simples comparaisons ;
- ‘quote‘ force l’utilisation d’un type de guillemets donné ;
- ‘semi‘ oblige ou non l’utilisation du point-virgule.
Pour avoir la liste complète des règles supportées par ESLint, rendez-vous ici : https://eslint.org/docs/rules/
Désactiver localement une règle ESLint
Il est possible de désactiver localement et exceptionnellement une règle ESLint définie dans le fichier de configuration. on peut en avoir besoin notamment si on fait face à un cas particulier qui nécessite l’abolition d’une règle simplement sur une ligne ou un fichier.
Cela se fait grâce aux commentaires.
Par exemple, si on veut désactiver l’obligation de la triple égalité sur une ligne, on ajoutera en commentaire juste avant celle-ci :
// eslint-disable-next-line eqeqeqTout simplement.
ESLint + frameworks JavaScript
ESLint, c’est bien beau si vous faites du VanillaJS, mais si vous utilisez des frameworks JavaScript, tels que React, Angular ou Vue, comment faire ?
Eh bien, il y a des plugins pour adapter le linter à ces frameworks. Mais ce n’est pas tout, il existe tout un tas d’autres extensions pour l’utilisation spécifique de certains outils ou librairies, comme jQuery ou MongoDB.
Vous retrouverez la liste complète des plugins ESLint ici : https://github.com/dustinspecker/awesome-eslint#plugins
Aller plus loin
On a déjà fait un bon tour d’ESLint, et comme vous l’avez vu, c’est un outil très complet, qui, s’il est bien configuré, peut se révéler très puissant.
Cependant, on peut aller encore plus loin avec ESLint.
On l’a déjà rapidement évoqué, mais il est possible, par exemple, d’empêcher un commit si le code ne respecte pas les règles définies dans le fichier de configuration.
Pour cela, on utilise des plugins comme yorkie ou husky.
Par exemple, une fois yorkie installé, il suffit de rajouter dans le package.json les lignes suivantes :
{
"scripts": {
"lint": "eslint --max-warnings=0 ."
},
"gitHooks": {
"pre-push": "npm run lint"
}
}
Pour que, juste avant un commit, le linter soit exécuté, et donc fasse échouer le commit en cas de non respect des règles.
Si cela peut se révéler utile pour uniformiser une codebase, encore une fois, trop de règles et des règles trop strictes peuvent se montrer contre-productives…
Et vous, quelles ont-été vos expériences avec ESLint ? Dites-le nous en commentaire !
