Un linter est un outil d'analyse statique de code source. Il sert à détecter :
- des erreurs (très utile sur des langages interprétés comme JavaScript qui n'ont pas de phase de compilation) ;
- des problèmes de syntaxe et de non-respect de style (tabulation vs espaces, indentation, etc.).
Aujourd'hui l'usage d'un linter dans les projets ne fait plus débat, c'est obligatoire. L'absence d'usage d'un linter est un signal fort indiquant un manque de professionnalisme et de sérieux, comme l'absence d'automatisation des tests ou l'absence d'outil de gestion de versions de code source (SCM).
Au-delà de la détection d'erreurs et d'une démarche qualité, l'usage d'un style-guide permet de dépersonnaliser le code source et de faciliter considérablement les opérations de fusion de branches avec tous les SCM.
Courte histoire des linters dans le monde JavaScript
Le premier linter JavaScript est JSLint. Il a été écrit par Douglas Crockford en 2002. Il est aujourd'hui largement obsolète ne supportant pas les évolutions de JavaScript postérieures à ES5. Il présente aussi de nombreux défauts, dont une absence quasi totale de possibilité de configuration et d'extension. Il est cependant toujours maintenu par son auteur qui semble ajouter les nouveautés de l'ES2015 au compte-goutte.
JSLint a été forké en 2010 pour aboutir à la création de JSHint, une version de JSLint configurable. Il est toujours maintenu.
Autour de 2013/2014, le projet JSCS est né afin de fournir à la communauté un outil de vérification de style de code extensible et configurable. De nombreuses organisations ont publié leur "presets", Airbnb, Google, jQuery…
Au milieu de l'année 2016, les membres du projet JSCS ont pris la décision de fusionner avec l'équipe ESLint. JSCS est aujourd'hui déprécié.
ESLint, le standard de facto
ESLint constitue une synthèse des linters précédents et est devenu le standard de facto. Il regroupe toutes les fonctionnalités et tous les avantages de ses prédécesseurs avec une documentation d'une qualité exceptionnelle.
On peut l'utiliser « out-of-the-box » avec la configuration par défaut, on peut le configurer, on peut l'étendre, il bénéficie d'une adoption très forte et dispose donc de nombreux plugins ajoutant des règles pour supporter toutes les spécificités imaginables :
- support des différentes versions d'EcmaScript (6, 7, 8...) ;
- support de l'API DOM ;
- support de Node.js ;
- support des différents frameworks (plugins pur AngularJS, Vue, React...) ;
- support de bibliothèques (lodash, ramda...) ;
- support de bonnes pratiques (sécurité, programmation fonctionnelle, immutabilité, etc.).
Il s'intègre aussi très bien dans un grand nombre d'éditeurs et d'outils de développement.
les supersets de ESLint
Aujourd'hui, si la question du choix technique du linter ne se pose plus, la question du style de code à utiliser se pose encore, et à vrai dire, elle ne pourra jamais être tranchée.
Sur la base de ESLint, certaines entreprises ou communautés ont construit leurs propres standards pour trancher les débats stériles du type « spaces or tabs », mais toutes utilisent ESLint au cœur.
Certaines publient une configuration ESLint sous forme de package comme Airbnb ou Google, d'autres ont pris le parti d'écrire des packages encapsulant ESLint comme standardJS.
L'avantage de ces supersets est de s'éviter les batailles de chapelles entre développeurs et une longue et fastidieuse configuration, en adoptant un standard préconfiguré et immuable.
Le standardJS semble devenir doucement le standard de coding style de l'open source JavaScript, des milliers de packages l'ont en dépendance et des contributeurs massifs l'utilisent sur leurs projets comme NPM, GitHub, mongoDB ou ZenDesk.
ESLint en 4.19.0
Le 16 mars 2018, ESLint a publié la version 4.19.0 de son package sur npm.
Elle ajoute notamment :
- le support des nouvelles fonctionnalités sur les expressions régulières de ES2018 ;
- l'ajout d'une option consecutive sur une règle très utilisée à propos de la déclaration des variables en début de fonction.
standardJS en 11.0.0
De son côté standardJS a publié le 18 février dernier la version 11.0.0.
Il s'agit principalement d'une mise à jour des dépendances sur ESLint et les divers plugins ESLint utilisés (node, promise, react...)
Sources :
- Blog ESLint
- Changelog standardJS
Et vous ?
Utilisez-vous un linter sur vos projets ?
Utilisez-vous le coding style d'une autre société ou bien avez-vous pris le temps d'écrire le vôtre ?