Les linters JavaScript

Un linter est un outil d'analyse statique de code source. Il sert à détecter les erreurs, les problèmes de syntaxe et le non-respect d'un style ou des bonnes pratiques.

Une analyse statique consiste à scruter le code source pour obtenir des informations sur le comportement qu'il aura lors de son exécution, ceci sans avoir besoin de l'exécuter. C'est ce qui la distingue du débogage ou profiling.

Des linters existent dans quasiment tous les langages. Sur les langages compilés, des linters sont intégrés au compilateur et aux IDE. Sur les langages interprétés, comme JavaScript ou PHP, ils existent depuis de nombreuses années mais sont connus et utilisés depuis peu.

Quelle utilité ?

Qui n'a jamais râler contre un code incompréhensible, in-maintenable, auquel on a peur de toucher de peur de provoquer des régressions dans tous les sens ? Un bon moyen rapide et efficace pour diminuer les chances de produire ce type d'applications est d'intégrer le linting dans le processus de développement. De plus le linter permet à une équipe de développement, pouvant évoluer dans le temps, de conserver un code cohérent et conforme à des bonnes pratiques communes. Enfin, un linter permet aussi de traquer des mauvaises pratiques pouvant influer sur les performances.

Aujourd'hui, le linting est communément admis comme une bonne pratique indispensable sur un projet de développement, comme les tests, l'ajout de commentaires, les revues de code, etc.  Il peut être imposé en stoppant le processus de build ou en empêchant le push/commit à la moindre erreur détectée par le linter ou intégré de manière plus douce en incluant le linting comme une étape parmi d'autres dans les tâches de développement au jour le jour.

 

Offres disponibles

JSLINT

C'est le premier linter apparu pour JavaScript. Il a été écrit par Douglas Crockford en 2002. Il est aujourd'hui obsolète. Il ne supporte ni les évolutions de JavaScript postérieures à ES5, ni React. Il n'est pas configurable, n'est pas très bien documenté et n'offre pas la possibilité d'ajouter des extensions.

JSLint a été forké en 2010 pour aboutir à la création de JSHint.

 

JSHINT

Il a une communauté bien développée, est facilement configurable et support de nombreuses librairies. Il n'est en revanche pas possible d'ajouter des règles. Il supporte ni ES7 ni React.

 

ESLINT

Il a été créé par Nicholas C. Zakas en 2013. Largement au-dessus du lot, il est devenu le standard. Il est très bien documenté (malgré qu'il soit un peu plus lent). Il est conçu pour être facilement personnalisé et étendu (chaque règle est un plugin). Grâce à son succès, de nombreux plugins sont aujourd'hui disponibles pour supporter les dernières versions d'EcmaScript, l'API DOM, Node.js, Vue, React, et de nombreuses librairies (lodash, ramda, etc.). Il est également facilement intégrable dans de nombreux éditeurs et IDE : Sublim Text, Vim, Emacs, Atom, IntelliJ, Eclipse Orion ou Visual Studio Code. Enfin, contrairement aux linters précédents, les résultats d'analyse sont succins et claires.

 

Quel style ?

Aujourd'hui, si la question du choix du linter est facile à trancher, la question des règles à adopter est sujet à discussion.

Certaines entreprises ou communautés (comme Airbnb ou Google) ont construit leurs propres standards et publient une configuration ESLint sous forme de package. D'autres ont pris le parti d'écrire des packages encapsulant ESLint comme standardJS. L'avantage de ces standards pré configurés est d'éviter des arbitrages interminables et une configuration pénible.

 

ESLINT RECOMMENDED

Il n'est pas très restrictif et assure le service minimum en vérifiant les principes de base et n'applique qu'une seule restriction en matière de style : interdiction de mélanger des espaces et des tabulations pour l'indentation du code. Il peut être utile pour tester au départ l'utilisation d'ESLint indépendamment du choix du standard, mais il est recommandé de le surcharger ou de changer de standard pour l'utilisation finale sur un projet.

Il est décrit ici : https://eslint.org/docs/rules/ .

 

GOOGLE vs AIRBNB vs STANDARDJS

En ce qui concerne les 3 autres standards les plus populaires Google, Airbnb et StandardJs, on peut déjà indiquer qu'ils ont quelques points communs en matière de style. Ils préconisent ainsi tous les trois l'utilisation de :

  • Deux espaces pour l'indentation,
  • Simples quotes,
  • D'une indentation sur une seule ligne pour les blocs de contrôles,
  • De Const plutôt que var.

Pour ce qui est des différences, voici un petit comparatif pour quelques règles ESLint (fait avec l'aide de l'article de medium.com ) :

Le standard AIRBNB est le plus populaire. Le standardJS est aussi beaucoup utilisé dans le monde de l'open source JavaScript (des milliers de packages l'ont en dépendance, y compris par des gros contributeurs tel que NPM, GitHub, mongoDB ou ZenDesk), mais il est assez clivant du fait de son retrait des points-virgules. Si vous utilisez React, Airbnb offre plus de règles liées à ce framework que Google. En outre, de manière générale, Google propose des règles moins doctrinaires que Airbnb.

Voici les liens vers les 3 standards :

https://github.com/airbnb/javascript

https://github.com/google/eslint-config-google

https://github.com/standard/standard

Bien sûr, il vous est possible de piocher dans ces standards tout en ajoutant votre touche personnelle, ESLint étant conçu spécialement pour une configuration et une personnalisation très facile. Le tout étant de se mettre d'accord en amont au sein de l'équipe de développement pour garder une cohérence indispensable.

 

Limites

Les linters ne doivent pas totalement déresponsabiliser, ils ne sont ni infaillibles ni exhaustifs, la relecture de code et les tests sont également indispensables pour ne laisser passer aucune faille et conserver un code de qualité : un exemple ici : https://swizec.com/blog/javascript-linters-bugs/swizec/7800.

 

Pour en savoir plus, n'hésitez pas à visiter ces liens :

https://hackernoon.com/what-javascript-code-style-is-the-most-popular-5a3f5bec1f6f

https://blog.nathanaelcherrier.com/2016/03/07/linting-good-practices

https://codeburst.io/javascript-linting-tools-comparison-ebcb4aa23c49

https://fr.wikipedia.org/wiki/Analyse_statique_de_programmes

https://www.developpez.com/actu/193978/Suivi-des-linters-JavaScript-outils-d-analyse-statique-de-code-source-ESLint-en-4-19-0-et-standardJS-en-11-0-0

https://medium.com/@danielsternlicht/thoughts-about-javascript-linters-and-lint-driven-development-7c8f17e7e1a0

https://eslint.org/docs/user-guide/integrations

https://codeburst.io/javascript-linting-tools-comparison-ebcb4aa23c49

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.