Mise à jour du système de construction du code JavaScript

[Alexinfos]

Remplacement de Gulp par le bundler Vite.

Étapes à suivre :

• Compilation liée au CSS
• Production d'un sprite avec les icônes du site
• Minification des images
• Fichiers de police d'icônes
• Transpilation du Javascript
• Linting et formatting du Javascript
• Modification du Makefile pour utiliser Vite
• Retrait de Gulp

Fix #6447

Contrôle qualité

Instructions données plus loin dans la PR

[philippemilink]

Pourquoi est-ce qu'il est nécessaire de transformer tous les @import en @use / @forward dans les fichiers SCSS ?

[Convolutio]

Contrôle qualité

1. Sur la branche dev de zestedesavoir, lancer une compilation avec Gulp.

   make build-front

   Ensuite, renommer le fichier dist en correct-dist

   mv dist correct-dist

2. Aller sur la branche associée à cette PR et mettre à jour / installer les nouveaux modules node avec

   yarn install

3. Lancer une construction avec ViteJS avec la même règle du Makefile

   make build-front

4. Comparer les fichiers produits entre les deux construction grâce à ce script sh

   # all useless diff data have been deleted
   # also ignore .map files in the comparison
   cd dist/ && find . | sort > ../dist.fd &&\
   cd ../correct-dist/ && find . | sort > ../correct-dist.fd &&\
   cd .. && diff dist.fd correct-dist.fd \
   | grep -E '^(<|>)' \
   | sed 's/>/Manquant :/g; s/</En trop :/g' \
   | sed '/\.map$/d' \
   > build_comparison.diff &&\
   rm dist.fd correct-dist.fd

5. Inspecter le fichier build_comparison.diff produit par ce script. Normalement, seul des fichiers .woff et .woff2 non-utilisés par le css sont manquants. Des dossiers inutilisés par Django ont également été retirés, comme images/sprite/ et scss/.
   Ce script ne compare pas le dossier de sortie errors/css/ mais il est possible de vérifier que le fichier errors/css/main.css existe bien.
   Les fichiers de sourcemap ne sont pas encore produits mais ne sont pas nécessaires au bon service du Frontend par Django.

6. Enfin, lancer Django pour servir le frontend

   source zdsenv/bin/activate
   make run-back

7. Vérifier dans l'inspecteur de votre navigateur sur localhost:8000 que toutes les ressources sont chargées correctement

Vérification du remplacement des autres fonctionnalités de Gulp

Avec les dépendances de ViteJS installées,

1. S'assurer que le watch mode fonctionne en lançant make watch-front et en éditant un fichier de frontend (e.g. assets/scss/main.scss après un premier build. Normalement, un second (et peut-être un troisième) build devrait se lancer.

2. S'assurer que le linting est faisable avec la règle make lint-front

3. S'assurer que la commande de réparation automatique de certaines règles de linting fonctionne avec la règle make format-front

À corriger

• Pour le moment, le css produit ne résout pas correctement les chemins des images d'assets. (fixé !)

Remarques

• De nombreux warnings sur le css dûs aux dernières versions des préprocesseurs scss intégrés dans ViteJS devraient être affichés. Ils n'empêchent pas le bon déroulé de la construction du site de zds et peuvent donc être fixés à l'occasion d'une autre PR.
• De la documentation pour l'usage des url d'images dans les fichiers scss mériterait d'être rédigée pour que les développeurs puissent éditer du scss de manière adaptée au nouvel outil.
• Une construction par vitejs est encore assez lente à cause de la copie statique de librairies js et de fichiers de police. Ceci pourra être amélioré lorsqu'une intégration de vitejs avec Django pourra être mise en place. Il existe des plugins pour faire cela et le watch mode des fichiers de frontend pour alors être intégré dans un mode de développement de django (e.g. avec make run-back) et pourra bénéficier de 2 fonctionnalités clés de ViteJS permettant une accélération nette de la construction du frontend :
  • le pre-bundling des dépendances installées avec yarn et utilisées par les templates de django et les assets js
  • la fonctionnalité du Hot Module Replacement de vitejs accélère énormément la construction pendant une phase de développement avec watch mode

[philippemilink]

Je viens jeter un œil au code. J'ai l'impression que les tâches qu'il restaient à faire d'après le message initial de cette PR sont maintenant faites ?

En revanche, il reste à corriger les erreurs rapportées par le linter pour que la CI puisse passer et mettre à jour la documentation pour expliquer globalement comment fonctionne la construction du front.

[philippemilink]

À quoi sert ce fichier ?

[Convolutio]

Pour que vitejs traite des assets d'images (et les mettent au final dans le dist/), ces assets doivent être chargés dans un fichier source html, car le moteur (faignant/optimisé par défaut) ne traite que les assets réellement utilisés dans le frontend final. Ici, nous avons créé un frontend artificiel étant donné que le vrai est celui généré par django à partir des fichiers de template et des données du backend.

Je suis d'accord qu'on a là de l'ingénierie qui n'est pas produit habituellement dans les projets de vitejs, surtout que les projets vitejs qui comprennent ensuite un backend comme django utilisent généralement des plugins d'intégration pour que la construction en développement ou en production par vite se fasse en même temps que les constructions faites par django depuis ses templates (dans ce cas là, pas besoin alors de faire de fichiers pictures.html artificiels pour centraliser le chargement de tous les assets : on charge directement les assets utiles dans les fichiers de template de django)

[coveralls]

coverage: 89.225%. remained the same
when pulling 9a0cf93 on Alexinfos:vite
into e30e481 on zestedesavoir:dev.