On peut presque toujours parier qu’un bon morceau d’écriture a été le bienfaiteur d’une bonne édition. À cet égard, le code n’est pas différent de la prose. L’un des avantages dont nous bénéficions en tant que développeurs et programmeurs sont les éditeurs, ou linters de code, qui peuvent être intégrés dans nos flux de travail.

Linting est l’acte ou le processus de vérification de votre code pour les erreurs de toute nature. Il y a beaucoup de pensées sur la façon d’optimiser l’efficacité d’un morceau de code donné. Mais vérifier qu’il est exempt d’erreurs et qu’il respecte un guide de style particulier constitue la base de référence. Parfois, il s’agit d’une question de cohérence et de lisibilité, parfois il s’agit de faire en sorte que le code s’exécute réellement en premier lieu.

Lorsqu’il s’agit de linting JavaScript, il y a une poignée d’outils qui se distinguent. Examinons quatre linters qui peuvent vous aider à démarrer ou à affiner votre processus de linting : JSLint, standardJS, JSHint et ESLint.

JSLint

JSLint a été créé en 2002 par Douglas Crockford, qui a également écrit ce qui est sans doute l’un des meilleurs livres sur JavaScript. JSLint apporte la simplicité et la vitesse à la table. Mais il est également très opiniâtre, ce qui peut être une bénédiction ou une malédiction.

JSLint consiste en un site à page unique qui est dominé par un champ de texte où vous pouvez coller votre code. Cliquez sur le bouton ‘JSLint’ et les erreurs, stylistiques, syntaxiques ou autres, s’afficheront sous le champ de texte. Sous le champ de texte se trouve une petite liste d’options, configurables par des cases à cocher. Les options incluent la tolérance d’espaces blancs supplémentaires, l’utilisation du mot-clé ‘this’ (qui est déconseillé par Crockford dans ses conférences), et l’inclusion de Node.js.

Si vous n’êtes pas redevable à un guide de style particulier et que vous voulez une source fiable pour vérifier votre code pour vous, JSLint est une excellente option. Il est particulièrement efficace pour tester des extraits de code ou si vous cherchez un moyen de lint rapidement de petits projets – peut-être un site statique d’une seule page qui ne contient qu’un seul fichier JavaScript.

standardJS

Selon les seules étoiles de GitHub, standardJS est l’option la plus populaire, arrivant à près de 19 000 étoiles. Il est entièrement basé sur l’opinion, ce qui signifie qu’il n’est pas du tout personnalisable. Mais, si vous n’êtes pas redevable à un guide de style particulier, cela peut être une bénédiction. Il se présente sous la forme d’une CLI Node, et peut être installé globalement ou comme une dépendance de développement en utilisant votre terminal ou la ligne de commande de votre choix :

$ npm install standard --global// or$ npm install standard --save-dev

Parce que standardJS a Node et npm comme prérequis, et parce qu’il est exécuté à partir de la ligne de commande ou par un script npm, la barre est légèrement relevée par rapport au niveau de JSLint. Mais comme il n’est pas configurable, vous n’avez pas beaucoup d’autres soucis à vous faire. Vous pouvez l’exécuter depuis la ligne de commande comme une commande d’un mot et il vérifiera chaque fichier avec une extension .js dans votre répertoire de travail actuel.

Toutes les erreurs qu’il trouve seront imprimées sur votre terminal ou votre ligne de commande. Vous pouvez vous attendre à voir une sortie similaire à cet exemple tiré de la documentation standard de JS :

$ standardError: Use JavaScript Standard Stylelib/torrent.js:950:11: Expected '===' and instead saw '=='.

Si vous devez spécifier un fichier ou un répertoire, vous pouvez inclure le chemin d’accès comme argument et utiliser des caractères génériques. Il accepte également les caractères génériques. Dans cet exemple, standardJS va rechercher et lint tous les fichiers JavaScript dans le répertoire src et ses sous-répertoires:

$ standard "src/**/*.js" --fix

Le drapeau --fix après le chemin d’accès au fichier est l’option pour corriger automatiquement les erreurs au fur et à mesure qu’elles sont trouvées. Cela peut être un grand gain de temps, mais cela pourrait aussi être un grand exercice d’apprentissage pour corriger les erreurs vous-même.

Si vous voulez explorer les conventions et les règles que standardJS utilise avant de décider de l’utiliser, une liste complète peut être trouvée ici. StandardJS est une excellente option pour ceux d’entre vous qui cherchent un moyen rapide et fiable de démarrer avec un linter JavaScript.

JSHint

JSHint a commencé comme un fork de JSLint. L’objectif était de faire un linter plus configurable. Si vous avez utilisé standardJS, ou un autre linter opiniâtre, et que vous cherchez un moyen de commencer à personnaliser vos propres règles de linting, JSHint pourrait être pour vous. Il présente la plupart des avantages des linters susmentionnés et même plus.

Comme JSLint, la page d’accueil de JSHint présente un champ de texte où vous pouvez coller du code. Le champ Metrics à droite du champ de texte se met à jour en temps réel au fur et à mesure que vous tapez, comptabilisant une liste de statistiques sur votre code, comme le nombre de fonctions qu’il contient. Bien sûr, il affiche également toutes les erreurs de linting qu’il trouve.

Si vous n’aimez pas la méthodologie du copier/coller et que vous voulez l’intégrer dans votre projet, JSHint peut être installé globalement ou comme une dépendance du projet en utilisant npm:

$ npm install jshint --global// or$ npm install jshint --save-dev

Une fois installé, vous utiliserez le CLI pour linting votre code. Voici deux exemples de commandes qui vérifient un seul fichier et un répertoire, respectivement:

$ jshint index.js// or$ jshint src/

Dans le premier exemple, JSHint va lint le fichier index.js et dans le second, il va rechercher récursivement le répertoire ‘src/’ et lint tous les fichiers JavaScript qu’il trouve. JSHint imprimera toutes les erreurs qu’il trouve dans votre terminal.

Si vous ne vous souciez pas de la personnalisation, JSHint peut être utilisé comme décrit dans les exemples ci-dessus et il fonctionnera très bien. Mais, à partir de là, la complexité peut monter en flèche de manière significative parce que JSHint est complètement configurable et qu’il expose également une API, ce qui signifie qu’il peut être utilisé comme un module JavaScript dans vos propres fichiers JavaScript.

Une configuration personnalisée, qui devrait être stockée dans un fichier nommé .jshintrc, fichier pourrait ressembler à ceci:

{"esversion": 5,"eqeqeq": true,"strict": true}

Cet exemple, de haut en bas, définit la version ECMAScript à 5, exige l’utilisation de trois signes égaux ( === ou !==) par opposition à deux (== ou !=) lors de la comparaison des valeurs, et applique le mode strict. Vous pouvez inclure vos configurations personnalisées en spécifiant le chemin d’accès à votre fichier .jshintrc derrière un drapeau -- config à la ligne de commande ou en les déclarant comme attribut ‘jshintConfig’ dans le fichier package.json de vos projets. JSHint utilisera ses options par défaut pour toutes les règles que vous ne personnalisez pas.

L’option de la ligne de commande pourrait ressembler à ceci:

// looks for '.jshintrc' in the current directory$ jshint --config './.jshintrc'

Alors que l’option package.json pourrait ressembler à ceci:

{ "jshintConfig": { "esversion": 5, "eqeqeq": true, "strict": true }}

Vous pouvez utiliser ces bases pour commencer sur la voie de la personnalisation de vos propres règles de linting avec JSHint. Si vous cherchez plus, les docs officiels contiennent une description exhaustive de la façon d’utiliser l’API JSHint et toutes les façons dont il peut être personnalisé pour répondre à vos besoins.

ESLint

Les étoiles de GitHub mises à part, quand il s’agit de linting JavaScript ESLint est probablement le linter vu le plus dans la nature et va être le go-to pour beaucoup de gens. Dans sa propre documentation, il se compare à JSLint et JSHint en ce qui concerne les méthodes qu’il utilise pour analyser JavaScript. Et, comme pour JSHint, vous vous facilitez la tâche en utilisant des valeurs par défaut et ajoutez des personnalisations au fur et à mesure que vos préférences ou vos besoins changent.

Pour commencer avec ESLint, installez-le globalement ou comme une dépendance de développement :

$ npm install eslint --save-dev// or$ npm install eslint --global

Si vous installez ESLint globalement, ses configurations s’appliqueront à tous les fichiers de projet contre lesquels vous l’exécutez. Mais si vous voulez différentes configurations pour différents projets, vous pouvez l’installer comme une dépendance de développement et créer un fichier de configuration différent pour chaque projet. Soyez conscient que si ESLint est installé comme une dépendance de projet, par opposition à globalement, vous devez exécuter l’exécutable à partir de votre dossier node_modules comme suit:

$ ./node_modules/.bin/eslint --init

Lorsque vous exécutez la commande ci-dessus, vous serez guidé à travers la configuration de ESLint par une série de questions. (Note : Indépendamment de la façon dont vous prévoyez de personnaliser vos règles de linting, vous devez commencer par cette étape car ESLint a besoin du fichier .eslintrc qui sera généré par ce processus avant de pouvoir linting votre code.)

La première question qui vous est posée est de savoir comment configurer ESLint. Vous avez trois options : utiliser un guide de style populaire, répondre aux questions sur votre style, ou laisser ESLint se configurer pour vous en inspectant vos fichiers pour décider comment configurer les règles. Si la perspective de le configurer vous-même dès le départ semble intimidante, vous pouvez vous rabattre sur l’utilisation d’un guide de style populaire développé par l’une des quelques organisations connues.

Quoi qu’il en soit, ESLint utilisera vos réponses pour générer un fichier nommé .eslintrc dans le répertoire de travail actuel. C’est ce fichier que vous modifierez si vous voulez apporter des changements aux règles de linting plus tard sur la route.

Voici un exemple de fichier .eslintrc au format JSON qui utilise les règles par défaut du guide de style JavaScript d’Airbnb et inclut deux règles personnalisées pour désactiver le mode strict et autoriser les déclarations console.log():

{ "extends": "airbnb-base", "rules": { "strict": "off", "no-console": "off" }}

Si vous choisissez de répondre à des questions sur votre style, il vous demandera notamment quelle version d’ECMAScript vous utilisez, si vous préférez les tabulations ou les espaces, les points-virgules ou non, et si vous utilisez JSX et/ou React. Le support prêt à l’emploi d’ESLint pour React et les plugins supplémentaires vont probablement en faire le meilleur choix pour les développeurs React. Au moins pour ceux qui débutent avec le linting.

Après que ESLint soit installé et qu’un fichier .eslintrc ait été généré, vous pouvez utiliser le CLI pour commencer à linting votre code. ESLint recherche votre fichier .eslintrc par défaut, vous n’avez donc pas besoin de spécifier de configuration à la ligne de commande. Mais vous pouvez utiliser divers drapeaux pour modifier le comportement de ESLint. Dans l’exemple ci-dessous, le drapeau -- quiet indique à ESLint de n’afficher que les erreurs, par opposition aux avertissements et aux erreurs. Le drapeau --fix lui indique de tenter de corriger automatiquement toutes les erreurs qu’il trouve.

// run eslint against file1.js$ ./node_modules/.bin/eslint file1.js// run eslint against file1.js and file2.js with flags to modify behavior$ ./node_modules/.bin/eslint file1.js file2.js --quiet --fix

Comme avec les autres CLI dont nous avons parlé, vous pouvez utiliser des jokers et des chemins de fichiers au lieu de noms de fichiers spécifiques si nécessaire. Bien que ESLint soit hautement configurable, il facilite la courbe d’apprentissage en utilisant un guide d’installation abordable pour sa méthode de configuration par défaut. Si vous cherchez à vraiment creuser avec des personnalisations, la documentation officielle contient d’excellentes explications sur tout ce que vous pouvez faire avec ESLint.

.