IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Outils Discussion :

Suivi des linters JavaScript, ESLint en 4.19.0 et standardJS en 11.0.0


Sujet :

Outils

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Expert confirmé
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 419
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 419
    Par défaut Suivi des linters JavaScript, ESLint en 4.19.0 et standardJS en 11.0.0
    Suivi des linters JavaScript,
    ESLint en 4.19.0, standardJS en 11.0.0

    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é.

    Nom : eslint.jpg
Affichages : 15034
Taille : 12,8 Ko

    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 ?

  2. #2
    Membre Expert
    Homme Profil pro
    Inscrit en
    Octobre 2011
    Messages
    2 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2011
    Messages : 2 910
    Par défaut
    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...)

  3. #3
    Expert confirmé
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 419
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 419
    Par défaut
    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

  4. #4
    Membre Expert
    Homme Profil pro
    Inscrit en
    Octobre 2011
    Messages
    2 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2011
    Messages : 2 910
    Par défaut
    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...

  5. #5
    Expert confirmé
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 419
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 419
    Par défaut
    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

  6. #6
    Membre Expert
    Homme Profil pro
    Inscrit en
    Octobre 2011
    Messages
    2 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Octobre 2011
    Messages : 2 910
    Par défaut
    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" ?

  7. #7
    Membre très actif

    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    506
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Novembre 2009
    Messages : 506
    Par défaut
    Citation Envoyé par Marco46 Voir le message
    Le standardJS semble devenir doucement le standard de coding style de l'open source JavaScript
    Donc sans ;
    Beurk...
    Même si on est d'accord c'est exactement le genre de débat stérile que standardJS veut éviter...

Discussions similaires

  1. [VS.NET] Liens relatifs et suivi des sessions ?
    Par Webman dans le forum ASP.NET
    Réponses: 6
    Dernier message: 18/11/2004, 21h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo