Améliorez votre processus de développement AngularJS avec Yeoman – partie 2

Développement AngularJS avec Yeoman : Grunt

Vous l’attendiez avec impatience, voici la deuxième (et dernière) partie de l’introduction à l’utilisation de Yeoman pour développer des applications Web avec AngularJS.

Cette fois, c’est Grunt qui est à l’honneur.

Grunt

Développement AngularJS avec Yeoman : le logo de GruntGrunt est le troisième outil de la suite Yeoman.

Il permet de démarrer et d’enchainer des tâches simples pour automatiser certaines parties du développement d’application : la compilation automatique de fichiers LESS en CSS pendant le développement, la minification des fichiers CSS et JavaScript lors la création du package, l’optimisation des images, …

En générant une application avec yo angular, plusieurs tâches sont créées automatiquement, mais il est possible d’en ajouter d’autres.

Là aussi il y en a pour tous les goûts, les extensions sont disponibles sur le site de Grunt.

Pour les installer, il suffit de saisir :

npm install <nom de l'extension> --save-dev

L’option --save-dev sert à référencer l’extension dans le fichier package.json. A l’instar des packages gérés par Bower, les extensions pour Grunt sont exclues du versioning (par git par exemple).

Ainsi, en cas de checkout du projet, il est nécessaire de les télécharger de nouveau avec :

npm install

Ces extensions sont stockées dans le dossier node_modules.

Si vous voulez plus de détail sur le configuration de tâches, je vous conseille ce tutoriel vidéo.

Utilisation automatique des librairies Bower

L’une des tâches définies par défaut pour une application créée avec yo angular (depuis peu en fait) est bower-install.

Elle permet, après l’installation d’un package avec Bower, de l’inclure au bon endroit dans le fichier index.html, en saisissant :

grunt bower-install

En clair, cette tâche ajoute automatiquement la balise <script src=""> pour une librairie JavaScript et <link href=""> pour le CSS.

Ce n’est pas grand chose, mais cette fonctionnalité est tout de même assez pratique.

En revanche, comme souvent avec l’automatisation, le risque d’oubli du reste du travail augmente. Par exemple, la plupart du temps avec les librairies AngularJS, l’inclusion dans le fichier index.html n’est pas la seule étape pour pouvoir les utiliser dans le code : il est aussi nécessaire de la déclarer dans les modules du fichier app.js.

Phase de développement

Grunt vous aide aussi pendant le développement de votre application, tout d’abord avec un mécanisme de surveillance des fichiers que vous modifiez, à plusieurs niveaux :

  • affichage et rechargement automatique de la page dans le navigateur, le célèbre live reload, en cas de modification d’un fichier HTML
  • rechargement automatique et vérification de la syntaxe pour les fichiers JavaScript.
  • rechargement automatique et ajout de préfixes (les fameux -moz et -webkit) au nom des propriétés quand c’est nécessaire pour les fichiers CSS

Tout ceci se fait grâce à la commande :

grunt serve

Et vous pouvez ajouter d’autres tâches à exécuter automatiquement lors de la modification de fichiers, comme la compilation de fichiers LESS ou SASS, le cas échéant.

Vérification du code

La vérification du code JavaScript est faite automatiquement lorsque grunt serve est démarré, mais vous pouvez également le faire manuellement, en saisissant :

grunt jshint

L’intérêt de cette vérification est la mise en commun des bonnes pratiques de codage entre les différents membres de l’équipe.

Les conventions proposées par défaut, et que je trouve notables, sont :

  • vérification de l’indentation : peu importe si votre choix se porte sur les espaces ou les tabulations, le principal est de garder une indentation cohérente sur tout le fichier.
  • vérification des points-virgules : JavaScript permet de ne pas mettre de point-virgule à la fin des lignes, mais en mettre inconditionnellement permet d’éviter des erreurs souvent compliquées à diagnostiquer.
  • les accolades pour les blocs if, for, while, … sont obligatoires, même lorsqu’ils ne contiennent qu’une instruction. En effet, oublier de les ajouter en cas de nouvelle instruction est tellement facile.
  • utilisation des guillemets simples pour délimiter les chaines. Une explication pourrait être que l’HTML utilise les guillemets doubles pour les attributs. Il ne reste qu’à utiliser les quotes simples à l’intérieur.
  • utilisation de l’opérateur d’égalité ou d’inégalité strict, c’est-à-dire utiliser === plutôt que == et !== plutôt que != (pour rappel, les premiers testent le type en plus de la valeur).

Si certaines de ces règles ne vous conviennent pas, vous pouvez toujours les modifier dans le fichier .jshintrc présent à la racine du projet.

Enfin, si par exemple vous utilisez jQuery, cette ligne de commande :

jQuery.inArray(1, [1, 2, 3]);

sera correcte mais retournera une erreur de syntaxe, comme jshint ne connait pas jQuery.

Ainsi, il est nécessaire dans le déclarer dans la partie globals du fichier .jshintrc, par exemple :

"globals": {
"angular": false,
"jQuery": false
}

Notez que la valeur est false. C’est normal.

Test

Grunt propose également de lancer des tests unitaires (avec le framework Jasmine) et de bout en bout (avec ng-scenario) pour karma.

Pour les lancer, il suffit de saisir :

grunt test

L’exécution est automatique au moment de la modification d’un test lorsque grunt serve est en cours.

Création de package

Enfin, une fois le développement terminé, avec une syntaxe JavaScript valide, et testé, il ne reste plus qu’à le packager avec la commande :

grunt build

Comme son nom l’indique, cette commande construit le package a distribuer au client ou à installer sur le serveur. Il est généré dans le dossier dist.

Au programme (par défaut avec yo angular) :

  • minification et combinaison en un minimum de fichiers CSS et JavaScript, y compris les fichiers AngularJS (les contrôleurs, directives, filtres, …).
  • ajout de préfixes pour les fichiers CSS
  • les fichiers minifiés sont renommés avec un nom généré pour éviter les problèmes de cache

Et comme pour grunt serve, il est toujours possible d’ajouter des tâches à exécuter à ce moment là, comme la création d’un tag git, l’optimisation des images, la copie sur le serveur de production, …

Enfin, un inconvénient ressort (il en fallait bien au moins un) : le dossier bower_components est recopié complétement de la version de développement vers la version de distribution, ce qui peut représenter plusieurs Mo d’espace disque.

Sur un serveur Web, le problème n’est pas flagrant, mais si l’application est destinée à être compilée pour smartphone ou tablette, le fichier final sera d’autant plus lourd.

Ainsi, une petite séance de configuration de la tâche de copie sera nécessaire. En même temps, ce n’est pas très compliqué.

Grunt tout court

Enfin, pour lancer la séquence de vérification de la syntaxe (grunt jshint), celle de tests (grunt test) et dans la foulée, si les tests se sont bien déroulés, la construction du package (grunt build), il suffit de saisir :

grunt

Tout simplement.

Le mot de la fin

Yeoman est pratique et facile, et il fait gagner beaucoup de temps. En plus il est plutôt fun à utiliser, autant qu’AngularJS en fait. Alors autant lier l’utile à l’agréable.

Il existe plusieurs articles sur le Web à propos de Yeoman et de son utilisation avec le générateur AngularJS. Considérez celui-ci comme une base pour d’autres articles à venir sur ce blog.

Cet article vous a été utile ? Partage it !

4 réflexions au sujet de « Améliorez votre processus de développement AngularJS avec Yeoman – partie 2 »

  1. Un grand merci pour ces éclairages
    Avec les conseils d’utilisation des outils yeoman et le lancement du generateur Angular
    un régal
    mais dans l’appli générée les caractères accentués sont ‘incompris’
    alors que dans du codage Angular ‘à la main’ tout roule

  2. Bonjour,

    Merci pour cet article très intéressant !

    Pour m’être penché un peu sur la question de l’injection des dépendances CSS et JS dans les fichiers HTML, bower-install (qui tourne avec wiredep) semble quand même avoir un très gros inconvénient non négligeable : il sélectionne les fichiers JS et CSS se trouvant dans le bower.json de chaque dépendance (attribut « main »). Ainsi, si la dépendance dispose d’un bower.json qui n’est pas à jour, et qui ne donne pas un « main » cohérent et complet, alors cela ne fonctionne pas complètement…

    Avez vous trouvé des solutions pour pallier à ce problème ? Merci d’avance !

    1. Bonjour Florent,

      J’ai eu quelques rares soucis, une seule fois en fait, où j’avais dû exclure des fichiers dans la configuration de Grunt.
      J’explique tout ici : http://www.partage-it.com/exclure-des-fichiers-ajoutes-automatiquement-avec-grunt-bower-install/
      Par contre, dans le cas inverse, quand wiredep a un doute, il le notifie bien et nous laisse ajouter la dépendance manuellement. J’ai rencontré ce cas avec la librairie client socket.io.

      David

Laisser un commentaire

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

Si vous le souhaitez, renseignez le champ 'Nom' de cette façon : 'VotreNom@VotreMotClef' pour obtenir une ancre optimisée pour les moteurs de recherche.