tech(pdf): replace wkhtmltopdf (no longer maintained) with grover

[Holist]

#2439

wkhtmltopdf est déprécié depuis quelques années maintenant et doit être remplacé.
Les environnements virtuels Ubuntu ne le prennent plus en charge (On a du setup la CI de GH récemment pour que celle ci continue à fonctionner ici)
Il est temps de changer.

Plusieurs choix s'offrent à nous pour générer des PDFs :

Approche	Description	Exemples	Avantages	Inconvénients
Via Navigateur Headless	Utilise Chrome/Firefox en mode headless. Converti le HTML/CSS en PDF	Grover, Puppeteer	Rendu moderne et fidèle, simple d'utilisation	- Dépendance à DevTools et Chromium - Temps de démarrage du navigateur headless à chaque génération
Moteurs de rendu dédiés	Bibliothèques spécialisées PDF (Gratuit ou payant). Pas de dépendance navigateur	WeasyPrint, PrinceXML	Plus léger, meilleur support CSS print	- Installation plus complexe avec nombreuses dépendances système - Différences possibles de rendu avec les navigateurs modernes - Coût significatif pour solutions payantes
Génération programmatique	Construction du PDF via code. Pas de HTML/CSS	Prawn	Contrôle total du rendu	- Pas de réutilisation directe du HTML/CSS existant - Courbe d'apprentissage importante - Maintenance plus complexe (rendu en code) - Difficulté avec layouts complexes - Temps de développement initial plus long

Pour notre usage je pense que la gem Grover basée sur Puppeteer et Chromium répond à nos besoins qui sont assez simples (lettre standard) tout en étant facile à utiliser et à faire évoluer au besoin.

Quelques détails techniques

J'ai du mettre à jour eslint-config-airbnb pour installer Puppeteer.
On dois charger la police Marianne en base64 dans le css directement car Puppeteer et le navigateur headless n'a pas accès aux ressources et aux fichiers. (On aurait pu mettre un lien vers un cdn mais je n'ai pas trouvé la police sur un CDN).
J'ai du ajuster (ce qui m'a pris le plus de temps) le css existant, en utilisant flexbox. J'ai aussi ajouté une classe dédiée pour l'adresse de l'usager afin que celle ci (en absolute) soit bien positionnée pour les enveloppes à fenêtres. (Testé et validé par l'agent référent de l'Ardéche)
La génération de pdf fonctionne beaucoup mieux en environnement de développement (2/3 des fois ou je tentais de générer des pdf avec wickedpdf j'avais des symboles incompréhensibles dans le document).
Il y a un fix pour pouvoir utiliser les dernières versions d'Ubuntu dans la CI, il faut désactiver appArmor. Plus de détails ici : puppeteer/puppeteer#13196

Un exemple de pdf :

Invitation_1738670141_Barthelemy_Maurice.pdf

[Holist]

il s'agit de nouvelles règles introduites par la mise à jour de "eslint-config-airbnb" qui était nécessaire pour l'installation de "puppeteer". Plutôt que de fix les erreurs sur du code react qui va bientôt disparaitre j'ai ajouté ces règles en exception.

[Holist]

Bonne idée pour l'hébergement sur Scaleway de la police Michaël mais ça ne passe pas...
Je pense que la police distante n'a pas le temps de se charger avant la génération du pdf.
Pour éviter les problèmes je suggère de laisser tel quel avec la police en base64 dans le css.

[Holist]

cette méthode n'était pas utilisée

[aminedhobb]

Merci @Holist pour ce taff 🙏 🚀 !!
Trop cool d'enlever cette dépendance avec une solution qui marche comme avant 💪 !

J'ai fait quelque tests et il y a un truc que je trouve un peu gênant dans la nouvelle mise en page c'est le fait que l'adresse ne soit pas alignée avec l'en-tête comme dans l'exemple ci-dessous:

• Avant:

• Après:

Sinon à part ça il y a des petits changements au niveau de la taille des textes mais c'est ok pour moi, il faudra peut-être vérifier avec l'équipe produit que c'est bon pour eux aussi avant de déployer en prod.

[aminedhobb]

est-ce que du coup la CI fail si on enlève cette instruction ?

[Holist]

Tout à fait (uniquement les features tests de Grover), avec cette erreur :

      Grover::JavaScript::Error:
        Could not find Chrome (ver. 133.0.6943.53). This can occur if either
         1. you did not perform an installation before running the script (e.g. `npx puppeteer browsers install chrome`) or
         2. your cache path is incorrectly configured (which is: /home/runner/.cache/puppeteer).
        For (2), check out our guide on configuring puppeteer at https://pptr.dev/guides/configuration.

[aminedhobb]

Ok ça vaut peut-être le coup dans ce cas de rajouter un commentaire pour dire qu'on rajouter pupeteer pour les pdf (via grover)

[Holist]

La mise en production sur Scalingo pose des soucis :

Gestion des dépendances Node.js :

Le dossier node_modules est dans notre fichier .slugignore pour optimiser la taille du build sur Scalingo.
Puppeteer, contrairement aux autres dépendances qui ne sont plus nécessaire une fois que les assets sont compilés doit être disponible car Grover en a besoin pour contrôler le Chrome installé dans le build et générer le PDF.

Problème d'espace supplémentaire :

Puppeteer installe Chromium dans app/.cache
Cela ajoute un poids significatif au build (environ 500mb)

Solutions tentées sans succès :

Création d'un dossier puppeteer_modules séparé pour garder node_modules dans le .slugignore
Tentatives d'exclusion spécifique de Puppeteer du .slugignore. Malheureusement, .slugignore ne permet que des inclusions, pas d'exceptions

Solution possible et ses implications :

Retrait complet de node_modules du .slugignore
Impact sur la taille : passage de ~900MB à ~1.6GB
Rallongement du temps de build d'environ 1 minute

Perspectives d'évolution :

• Isoler Puppeteer pourrait économiser ~100MB puisqu'on supprimerai le reste du dossier node_modules en le remettant dans .slugignore
• Paramétrer Puppeteer pour utiliser une version plus légére de Chrome.
  Dans le meilleur des cas on pourrait tomber à 1.3GB ce qui reste une augmentation non négligeable et ajoute une dépendance importante au projet.
• Utiliser une app puppeteer externe pour ne pas impacter le build (ex : https://github.com/gip-inclusion/pdf-generator/tree/main)
• Trouver une autre solution d'export pdf

La PR reste pour l'instant ouverte mais compte tenu des implications cela nécessite plus de recherche et de travail pour trouver une solution de remplacement à wkhtmltopdf qui aurait moins d'impact sur le build et sur nos dépendances.