Suivi des linters JavaScript, outils d'analyse statique de code source,
ESLint en 4.19.0 et standardJS en 11.0.0

Le , par Marco46, Modérateur
Qu'est-ce qu'un linter

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 :



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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Beginner. Beginner. - Membre expérimenté https://www.developpez.com
le 17/03/2018 à 20:16
Merci.
Sujet intéressant et assez rarement traité pourtant c'est utile...

Je vais terminer de lire...

J’espère que d'autres sujets sur l'assistance seront traités (auto-complétion par exemple, refactoring, gestion de projets...)
Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 17/03/2018 à 22:02
J’espère que d'autres sujets sur l'assistance seront traités (auto-complétion par exemple, refactoring, gestion de projets...)
J'ai une forte appétence pour les sujets touchant à la gestion devops des projets et à la qualité. Depuis quelques semaines j'essaie de faire des news sur developpez au fil de ma veille techno donc oui yaura des news de ce type, ya plusieurs choses dans les bacs j'attends juste la sortie des versions finales
Avatar de Beginner. Beginner. - Membre expérimenté https://www.developpez.com
le 18/03/2018 à 0:47
Ah ben tant mieux... A suivre alors...

Sinon si j'ai bien compris ici tu as parlé des linters syntaxiques et j'ai cru comprendre qu'il y avait aussi des linters sémantiques que je vois plus rarement : par exemple j'utilise VSCode et il y a des plugins pour JSHint, ESLint... Mais j'en ai pas vu pour des "linters sémantiques"...

Voici le seul linter sémantique que je connaisse : https://github.com/angelozerr/tern-lint

On peut lire :
tern-lint is a tern plugin which is able to validate JavaScripts files to collect semantic errors. It is static type checker like flow. It's the main difference with other famous linters like JSHint, ESLint, JSCS which validate JavaScript files to collect syntax errors.

What do you mean with semantic errors? Invalid argument is a sample of semantic error :
Une liste des erreurs sémantiques traitées : https://github.com/angelozerr/tern-l...lidation-Rules.

---> Il tient aussi compte de la JSDoc : See Validation with JSDoc for more informations.

Connaissez-vous un outil ou un éditeur/IDE qui fasse aussi bien ou mieux ?

Par exemple WebStorm a-t-il ce genre de linter ? Pour VSCode je n'ai pas vu...
Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 18/03/2018 à 13:24
Le problème du linter sémantique c'est qu'il vient au croisement de beaucoup de choses. Probablement pour ça qu'il n' a pas pris, il ne semble plus maintenu d'ailleurs.

Il faudrait déjà définir ce qu'on appelle sémantique. S'il s'agit de savoir si une variable est déclarée mais inutilisée, ESLint fait ça très bien, la plupart des bons IDE le font naturellement aussi (Webstorm par ex).

S'il s'agit de typer explicitement les variables là c'est compliqué parce que d'autres outils font ça très bien et beaucoup de gens pensent (et je suis d'accord) que l'utilité est en soi contestable.

Je fais du JavaScript depuis quelques années maintenant après avoir utilisé des langages à typage fort et j'ai été perturbé au début par la gestion loose des types en JavaScript, mais depuis que je me suis mis au TDD vraiment sérieusement (quasiment à la même période) je ne me rappelle plus de la dernière fois où j'ai eu une erreur ou un bug du genre 1 + 1 = 11. Enfin ça m'arrive peut être de tomber sur ce genre de problème, mais c'est détecté et éliminé en 30 secondes dans la feedback loop du TDD. Input, output, comparaison avec expected, c'est tout ce qui compte en fait ...

C'est pourquoi je trouve l'utilité de TypeScript ou d'un outil comme Flow très contestable, quitte à passer du temps à améliorer son tooling pour augmenter la qualité autant le passer sur l'automatisation des tests, c'est bien plus utile à mon avis. Après Flow ou TypeScript c'est un problème de riche.

Pour contrôler les entrées sorties d'une API je trouve qu'un outil comme Joi ou ajv est beaucoup plus efficace.

Je ne sais pas si ça répond à tes questions
Avatar de Beginner. Beginner. - Membre expérimenté https://www.developpez.com
le 18/03/2018 à 13:49
Ben non justement il ne s'agit pas de typer explicitement les variables, c'est un point fort justement : il fait ça automatiquement, il établit le type d’après l'usage dans le code ou d’après la JSDoc (la JSDoc c'est une bonne chose, non ? On a ça en Java aussi...).

Et il ne s'agit pas seulement de savoir si une variable est déclarée mais inutilisée, ça va plus loin, il y a des exemples dans les liens...

Exemples :

- Pour document.getElementById(100); Il signale ceci "Invalid argument at 1: cannot convert from number to string".

- Pour new Date().setHours("hours"; Il signale ceci "Invalid argument at 1: cannot convert from string to number".

- Pour var b = true; document.addEventListener("", b, true); Il signale ceci "Invalid argument at 2: cannot convert from bool to Function.prototype".

Ca c'est juste des exemples pour l'erreur "invalid argument" mais il y a d'autres types d'erreur...

Autre exemple (propriété inconnue) :

- Pour document.body.a il signale " Unknown property 'a' ".

Est-ce que ESLint ou autre fait ça ?

PS : C'est quoi "TDD" ?
Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 18/03/2018 à 14:06
C'est quoi "TDD" ?
Test Driven Development.

C'est bien plus rentable de passer du temps à étudier ce sujet que tous les linters du monde !

Est-ce que ESLint ou autre fait ça ?
Non mais tes tests automatisés oui.

Pour la jsDoc le problème c'est que ça n'est utile que sur les API publiques pour générer automatiquement une documentation sur cette base. Pour toutes tes fonctions privées c'est simplement du temps perdu. Passe ce temps à écrire des tests clairs et tu auras une documentation exécutable contre ton code, c'est bien plus intéressant.

Enfin pour tout ce qui est relatif au DOM, tu vas utiliser la plupart du temps une couche d'abstraction au moyen d'une librairie (Vue, React, ...) ou d'un Framework (AngularJS, Angular, ...) et tu ne manipuleras presque jamais directement l'API DOM.
Avatar de Beginner. Beginner. - Membre expérimenté https://www.developpez.com
le 18/03/2018 à 14:30
Ok mais si on part du principe qu'avec les tests on détecte toutes les erreurs alors même les linter comme ESLint peuvent être remis en cause ? Pourtant on pense quand même qu'ils sont utiles, non ?

Mais même d'une manière générale est-ce qu'avec les tests on a plus besoin des linters même dans les autres langages ? Car finalement on peut toujours tester pour trouver les éventuelles erreurs, c'est vrai même dans les autres langage...

Sinon concrètement le TDD pour js tu le fais comment en pratique ?
Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 18/03/2018 à 17:03
Citation Envoyé par Beginner. Voir le message
Ok mais si on part du principe qu'avec les tests on détecte toutes les erreurs alors même les linter comme ESLint peuvent être remis en cause ? Pourtant on pense quand même qu'ils sont utiles, non ?
Si j'ai le choix entre mettre en place des tests ou mettre en place un linter, clairement ma préférence va au premier mais je vois pas pourquoi j'aurais pas le temps de mettre les deux.

Après ce n'est pas comparable avec un système de typage fort comme TypeScript ou Flow. Un linter vient interpréter le code existant pour t'indiquer ce que tu dois changer, TypeScript et Flow viennent dans ton code, ils modifient la façon dont tu vas travailler pour détecter des erreurs que j'aurais forcément vu sur les tests à l'exécution. Du coup je vois pas l'intérêt.

Les linters n'ont pas pour seul rôle de détecter des erreurs, ils ont aussi pour rôle de s'assurer que la syntaxe sera la même quel que soit le développeur (même indentation, espace ou tabs, ; obligatoire ou pas, etc ...).

En gros ESLint c'est code check + certaines erreurs, le linter "sémantique" que tu as linké c'est erreurs + typage fort et TypeScript / Flow c'est typage fort.

Comme le typage fort ne m'intéresse pas et que j'ai certaines erreurs détectées par ESLint je ne ressens le besoin de n'utiliser ni TypeScript / Flow ni le linter "sémantique".

Citation Envoyé par Beginner. Voir le message

Mais même d'une manière générale est-ce qu'avec les tests on a plus besoin des linters même dans les autres langages ? Car finalement on peut toujours tester pour trouver les éventuelles erreurs, c'est vrai même dans les autres langage...
Non mais on a besoin des deux. Je dis juste que l'investissement dans TypeScript ou Flow n'est pas rentable pour moi. Après si tu as dans ton équipe 90% de juniors il sera peut être rentable.

Citation Envoyé par Beginner. Voir le message

Sinon concrètement le TDD pour js tu le fais comment en pratique ?
Comme dans n'importe quel autre langage.

Je comprends pas trop la question, honnêtement c'est un sujet très très vaste c'est comme si tu me demandais c'est quoi concrètement la programmation avec js.
Avatar de Beginner. Beginner. - Membre expérimenté https://www.developpez.com
le 18/03/2018 à 17:27
Ok merci. Pour TDD c'est bon j'ai vu des trucs, oui c'est vaste mais j'ai vu qu'il y a quand même le principe : red-green-refactor... Après il y a des logiciels pour faire les tests et là ouais c'est vaste, je m'y perd...

Sinon pour moi typage fort ou faible, il y a quand même de vraies "erreurs sémantiques" dans l'histoire : si je mets un string en argument à la place d'un tableau ou autre, c'est bien que ce soit signalé...

Si j'utilise une propriété inconnue (une méthode par exemple que j'ai mal écrite (faute de frappe ou autre)) c'est bien que ce soit signalé...

Cela peut faire perdre du temps ces trucs-là quand même... C'est comme avec le css si tu mets une propriété inconnue ou une valeur, tu peux galérer pour trouver le problème...
Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 18/03/2018 à 18:51
Citation Envoyé par Beginner. Voir le message

Si j'utilise une propriété inconnue (une méthode par exemple que j'ai mal écrite (faute de frappe ou autre)) c'est bien que ce soit signalé...
Justement, en TDD tu vas prendre un "bidule is not a function" quand tu vas vouloir passer de red à green. Tu le vois immédiatement.
Contacter le responsable de la rubrique Accueil