Un code propre avec ESLint

Eric Burel

Published in

PointJS

5 min readJan 8, 2020

Les outils — Épisode 5

Linter ?

En anglais, lint signifie “retirer les retirer les peluches et les poussières à l'aide d'un chiffon doux”. Oui, ils ont bien un mot pour ça. En informatique, le linter va de même faire le ménage dans votre code source pour éliminer y les erreurs, bugs et autres saletés.

Une analyse qui se fait directement sur le code, comme s’il s’agissait d’un bout de texte quelconque, est dite statique. Comme tous les autres outils d’analyse statique (TypeScript par exemple), le linter ne garantit pas que votre code fera ce que vous voulez, ou qu'il ne déclenchera pas d'erreurs, mais il vous permet au moins d'être sûr qu'il tournera correctement et que vous respectez des bonnes pratiques.

Par extension, on utilise aussi cet outil pour uniformiser la syntaxe entre plusieurs développeurs. Par exemple le linter peut vous alerter si vous vous mettez à écrire du JavaScript avec des points virgules alors que le reste de l'équipe n'en utilise pas. Mieux, il peut les supprimer ou les ajouter automatiquement !

ESLint, toujours là pour nettoyer votre code!

🔨 Mettre en place ESLint

ESLint est de loin le linter JavaScript le plus répandu. Il est compatible avec la majorité des éditeurs de textes, ce qui vous permet de voir s'afficher les erreurs et les warnings directement dans votre code.

Installation

Rien de plus simple :

npm install eslint --save-dev

Vous pouvez maintenant configurer votre éditeur de texte pour prendre en compte ESLint, généralement en installant un package qui s'appelle... ESLint : ESLint pour VSCode; ESLint pour Atom etc.

Note sur les installations globales pour les CLI

Vous pouvez aussi utiliser ESLint en lignes de commandes en écrivant node_modules/.bin/eslint monfichier.js, c'est en fait ce que vont faire ces packages pour vous.

Vous pouvez même installer eslint de manière globale sur votre machine avec npm i -g eslint, vous pourrez juste écrire eslint monfichier.js. Mais je déconseille cette approche, car d'expérience cela pose des problèmes de versions entre celle installée sur votre machine et celle utilisée par votre équipe. Vous ne devriez installer que des outils réellement globaux avec l'option -g, c’est-à-dire de véritables logiciels en lignes de commandes.

Mon .eslintrc

Le fichier .eslintrc, à la racine de votre projet, permet de configurer ESLint. C'est grâce à ce fichier que vous allez définir les pratiques de programmation de votre équipe. Il s'agit d'un simple JSON :

{
  "rules": [
    "arrow-parens": "off",
    "consistent-return": "off",
    "comma-dangle": "off",
    "max-len": "off",
    "generator-star-spacing": "off",
    "no-unused-vars":"warn",
    "no-console": ["warn", { "allow": ["warn"]},
    "no-shadow": "warn",
  ]
}

Pour chaque règle les valeurs possibles sont "off", "warn", "error", vous pouvez aussi utiliser leur équivalents numériques 0, 1, 2 respectivement.

Vous pouvez ajouter des options en utilisant un tableau (règle no-console dans cet exemple), le premier élément est la valeur pour cette règle, le second contient ses options sous la forme d'un objet. Vous pouvez retrouver l'ensemble des règles fournies par Eslint et leurs options sur cette page.

Petit exercice : à quoi servent les règles no-shadow, max-len et comma-dangle ?

Un jeu de règles de base

Ne réinventons pas la roue, il existe des jeux de règles très bien faits et cohérents pour tous les goûts. Les trois plus célèbres sont :

eslint:recommended, fourni avec Eslint.
airbnb, le style... d'Airbnb, qui participe beaucoup à l'écosystème JS.
standard, mon style préféré. Son avantage majeur : pas de points-virgules. Après tout, cette publication s’appelle PointJS, pas PointVirguleJS.

Vous pouvez ajouter l'option "extends" : ["eslint:recommended"] dans votre fichier .eslintrc. Notez qu'il s'agit d'un tableau, vous pourrez ajouter d'autre règles, typiquement pour les plugins.

Avec Babel

Aujourd'hui, il est rare de rencontrer des fichiers écrits en JavaScript pur. ESLint risque alors de ne pas comprendre vos syntaxes et de signaler des erreurs pour rien.

babel-eslint permet de contourner ce problème : votre code sera transpilé avant d'être lu par ESLint:

npm i --save-dev babel-eslint

Dans votre .eslintrc ajoutez :

"parser": "babel-eslint"

Un environnement adapté

Deuxième problème : ESLint ne connaît que les variables globales propres au JavaScript (types de base comme String, Promise, etc.). Il ne va donc pas aimer les appels à window.localStorage par exemple, puisque window n'est pas déclaré dans votre code mais fourni par le navigateur.

Il suffit d'ajouter l'option env à votre .eslintrc pour signaler à Eslint que votre code est fait pour tourner dans le navigateur :

env: {
  "browser": true
}

Beaucoup d'environnements sont fournis par défaut, pour gérer les technologies majeures, vous pouvez les retrouver ici.

Des plugins

Enfin, ESLint nous permet de configurer des plugins pour gérer des technologies supplémentaires. Par exemple, si vous souhaitez utiliser Jest comme framework de test, vous aurez besoin d'eslint-plugin-jest. Vous pourrez aussi apprécier les plugins dédiés aux promises ou encore aux imports.

Voilà ce que vous pourrez ensuite ajouter à votre .eslintrc:

{
  "env": {
    ...
    "jest/globals": true
  },
  "plugins": [
    "import",
    "promise",
    "jest"
  ],
  "rules": {
    ...
    "import/extensions": "off",
    "import/no-unresolved": "error",
    "import/no-named-as-default": "off",
    "import/no-named-as-default-member": "off",
    "import/no-extraneous-dependencies": "off",
    "jest/no-disabled-tests": "warn",
    "jest/no-focused-tests": "error",
    "jest/no-identical-title": "error",
    "promise/param-names": "error",
    "promise/always-return": "error",
    "promise/catch-or-return": "error",
  },
}

Ignorez des fichiers

Enfin, créer un fichier .eslintignore à la racine vous permet d'ignorer des fichiers :

build
dist
coverage
node_modules
docs
static/*
!static/js

Validation et autofix

Voilà, vous avez complété votre premier fichier .eslintrc ! Assurons-nous désormais que notre code est toujours propre, en ajoutant deux commandes à notre package.json.

pour vérifier que le code est propre (lint)
pour corriger automatiquement les erreurs de lint (autofix)

Si vous avez bien configuré votre éditeur de texte, le lint et l'autofix se font déjà à chaque sauvegarde de fichier, mais cela reste une bonne pratique de lancer ces commandes avant chaque push important.

scripts:{
  "lint": "eslint --quiet --cache ."
  "lint-fix": "npm run lint -- --fix"
}

Et voilà, vous êtes désormais en mesure de garantir qu’à chaque instant, votre code et propre, sans le moindre travail supplémentaire !