Article
Création de logiciels
20.10.2017
Perturbation continuum temporel
3 minutes
Temps d'un café
Comment configurer Webpack dans un projet Angular ?
Comment configurer Webpack dans un projet Angular ?
Emilie Paillous
Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

Par la suite, nous avons essayé d’intégrer angular-cli au projet, mais il est impossible à date d’utiliser une configuration webpack personnalisée avec angular-cli, ce qui est un point assez bloquant. Voici les raisons qui nous ont amenés à personnaliser la configuration webpack, par rapport à celle proposée par le tutorial :

Sass

L’utilisation de SASS a été rapidement une évidence, puisque cela permet entre autres de stocker l’ensemble des couleurs utilisées à un seul endroit, et ainsi de pouvoir facilement les changer. Ceci n’est pas présenté dans le tutoriel, nous avons donc ajouté le loader Sass qui permet de compiler facilement du SASS vers du CSS. Par la suite nous avons gardé la structure proposée par le tutoriel, c’est à dire un fichier de style “global” (styles.scss) regroupant les styles utilisés partout au sein de l’application, et un fichier de style par composant, qui est chargé inline si le composant associé est utilisé dans la page.

Les fichiers SVG

Nous utilisons des fichiers SVG pour l’ensemble des images de l’application. Ces assets sont stockés dans un seul dossier public, puis référencés dans les différents templates. A l’aide du package inline-svg, ils sont inline à l’intérieur du html, ce qui permet par la suite de redéfinir les propriétés de l’image, comme la couleur, la taille des bords, etc.

Il n’est pas possible actuellement de référencer l’adresse d’un fichier SVG dans un modèle de l’application. Par exemple, nous souhaitions pouvoir référencer un pictogramme spécifique selon la classe de notre objet (par exemple, une méthode iconUrl() qui renverrait l’adresse du fichier SVG correspondant), mais l’adresse du fichier est relative au modèle et non au composant qui l’utilise, et webpack ne propose pas de solution pour régler ce problème. La solution mise en place actuellement est d’avoir un composant “pictogramme” prenant en entrée un type énuméré de pictogramme, et affichant le bon SVG suivant le type de pictogramme demandé.

Les variables d’environnement

Dans notre application, nous utilisons plusieurs système de taggage en parallèle nécessitant l’ajout d’un morceau de javascript dans la balise <head> de la page html. Nous utilisons des variables d’environnement afin de distinguer les données remontées par l’environnement de développement, de préproduction et de production. Au moment du build de l’application, nous utilisons le fichier JSON correspondant à l’environnement, répertoriant l’ensemble clé - valeur des variables d’environnement. En plus du plugin webpack déjà prévu à cet effet (EnvironmentPlugin), nous utilisons un simple loader de string replace afin de remplacer dans le fichier index.html les variables correspondantes.

Plusieurs fichiers de configuration webpack

Actuellement nous avons donc 4 fichiers nous permettant la configuration totale de webpack :

  • un fichier de configuration locale, identique à celui proposé par le tutoriel
  • un fichier de configuration de test, également identique à celui proposé par le tutoriel (remplaçant notamment les fichiers de styles et les images par null grâce au null-loader)
  • un fichier de configuration de production, dans lequel nous remplaçons les variables d’environnement référencées dans le fichier index.html, et dans lequel nous utilisons le plugin AoT permettant la compilation Ahead Of Time en production uniquement.
  • un fichier commun aux configurations de production et locale contenant les loaders commun (style, html, file, etc.)

Voici les liens vers nos différents fichiers :

webpack.common.js

webpack.local.js

webpack.prod.js

webpack.test.js

Un point important à remarquer (dans le fichier webpack.prod.js) concerne l’ordre dans lequel les différentes configurations sont mergées : en effet, le plug-in AoT doit être utilisé en premier avant toute autre configuration. Ainsi, webpackMerge prend trois arguments : une première configuration ne contenant que le plug-in AOT, une seconde configuration commune à la production et au développement local, puis la configuration propre à la production.

No items found.
Pour aller plus loin :