HTML5 : Optimisation des flux de production

Valider le code

Testez gratuitement nos 1300 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Vérifier le bon fonctionnement du code est une chose, mais valider la qualité est une étape tout aussi importante en production. Appuyez-vous sur Grunt pour obtenir les listes d'erreurs.
04:39

Transcription

C’est bien de vérifier le bon fonctionnement de nos fichiers JavaScript suite à l’utilisation de bower conjointement à npm, mais il est bon aussi de s’assurer de la bonne qualité d’écriture que l’on va pouvoir avoir dans le code lui-même, et JSHint, c’est une version un peu plus souple, on va dire, que l’hint, puisque l’hint est très rigoureux mais vous pouvez utiliser un grunt-contrib-jshint en toute sécurité pour pouvoir vérifier la bonne qualité de votre écriture de code. Alors pour cela, je vous invite à ouvrir la ligne de commande, d’aller directement dans le dossier numéro 11, de faire un npm install, puisque toutes les librairies sont prêtes, et puis une fois que c’est installé, de retourner regarder du côté de Gruntfile, alors ici on va travailler sous grunt c’est : on va utiliser le initConfig ici, avec le paramétrage de jshint en disant : on va rechercher dans le dossier JavaScript tous les fichiers JavaScript qui sont présents ici, alors il pourrait en avoir pléthore, c’est pas gênant. N’oubliez pas, si vous avez des dossiers incorporés à l’intérieur, de rajouter ici des variables avec un js/**/*.js de façon à pouvoir venir explorer l’intégralité de l’arborescence, et puis surtout comme options, utilisez un force true par défaut, qui va dire: s'il y a une erreur, tu t’arrêtes pas, tu continues, tu me les listes toutes, tu ne vas pas m'en faire qu'une. Alors, on va faire un registerTask sur validejs avec un jshint ici qui sera attaqué. Alors on va faire un premier test ici, on va retourner dans la console, et si on fait un grunt validejs, si on lance, on va se retrouver avec les erreurs que l’on va rencontrer. Donc on a 6 erreurs dans 2 fichiers. Ces 6 erreurs sont notamment dans le fichier 11.1 des absences de semicolon en fin de ligne, et puis ici une stricte équité qui n’est pas respectée puisque il y a un = =, alors qu’il serait mieux, lorsqu’on valide avec true, d’avoir un === pour être sûr d’être sur le booléen. Ensuite ici, encore une fois un semicolon qui manque. Alors c’est très bien, parce que ça nous permet d’avoir une feuille de travail, mais quelque part, on va être un petit peu limité dans la lecture de ces éléments-là, alors on va pouvoir venir dans notre grunt.js ici, rajouter un paramètre qui serait reporter, et ici on pourrait demander le reporter natif qui est jslint ou checkstyle. Alors si vous essayez avec jslint, vous allez avoir un fichier xml, donc on va relancer notre console, on rappelle la dernière tâche, on lance, et là donc, on est dans un fichier xml jslint qui nous liste l’intégralité des erreurs, donc après, bien entendu, on va pouvoir exporter ce fichier avec un logfile, on l’avait vu, ou le copier-coller, comme vous voulez. Maintenant on peut utiliser une deuxième option qui serait checkstyle, alors checkstyle, on va venir le remplacer ici. Voilà, CONTRÔLE-S, et puis on va relancer encore une fois de plus dans notre console. Alors je vais faire un petit clear pour mieux y voir ici, voilà. On revalide notre js, et là on obtient un xml également, mais un peu plus conçu, un peu plus succinct au niveau de l’écriture. Et maintenant, on va pouvoir retourner du côté de npmjs ici, et demander à travailler avec jshint-html-reporter. Et pour ça, on va pouvoir donc l’installer directement. Alors comme vous avez fait un npm install, rassurez-vous ça été installé. On va juste venir remplacer cette propriété-là par un require jshint-html-reporter, en disant : attention, on a besoin de cet élément là, et on va rajouter une propriété qui sera reporter, en disant que ce reporterOutput, on pourrait créer un dossier logs par exemple ici, et dire erreursJS.html par exemple ici, CONTRÔLE-S, on enregistre. Ici, on peut observer notre document, et dès l’instant où on va relancer notre validation, il nous dit : hop, ça a été reporté, ça a été créé, c’est terminé. Vous avez vu que c’était assez rapide en instruction, et effectivement ici, on a un fichier logs avec notre fichier erreurs qui est un pur fichier html qui a été reporté. Notamment, on peut maintenant venir explorer ce fichier html depuis un navigateur ici, et avoir l’ensemble des erreurs reportés en extérieur, en nous disant : voilà les erreurs sur le fichier js 11-1, et sur le fichier js 11-2, il y a 0 erreur, c’est 6 warnings qui sont faits, et ici vous avez les raisons. Voilà donc, de toujours penser à venir valider la bonne qualité de notre code, toujours avant de publier.

HTML5 : Optimisation des flux de production

Optimisez vos flux de production lors de vos développements en HTML5. Explorez les méthodes et les éléments essentiels à la mise en place de processus automatisés.

5h29 (62 vidéos)
Aucun commentaire n´est disponible actuellement
 
Spécial abonnés
Date de parution :26 déc. 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !