Closed laem closed 1 month ago
MAJ Clairement ramda reste le coup facile. Le seul fichier qui utilise beaucoup ramda c'est useNextQuestions.
Pour faire ces graphiques il faut utiliser https://www.npmjs.com/package/webpack-bundle-analyzer
yarn stats
pour générer le fichier JSON que bundle-analyser prend en entrée.
Ici une source non négligeable de réduction du poids, déjà faite par mon-entreprise : https://github.com/betagouv/mon-entreprise/commit/9ad8b0f18660432369458bde5a264793309f4a75
:heavy_check_mark:
Autre point important : on n'a pas besoin de publicodes-react avant d'aller sur la doc ! À intégrer dans les travaux sur le markdown, nécessaires pour la migration à la dernière version publicodes, chose faite sur futur.eco.
:heavy_check_mark:
@laem Est-ce que l'on peut considérer cette issue comme complétée, ou reste-il encore des optimisations à faire rapidement ?
Il reste Ramda à enlever dans la liste des tâches. Le sujet reste pertinent en permanence globalement : il faut surveiller le poids de temps en temps.
Nous utilisons des bib qui sont pas nécessaires :
[x] react-spring, alors que nous avons aussi framer-motion
[ ] lodash, et je ne sais pas d'où elle vient
[ ] ramda, assez peu utilisée depuis que les nouvelles fonctions en JS permettent de bien manipuler les arrays
[x] Nous avons aussi intérêt, probablement au préalable, de mettre à jour nos paquets, nombreux sont vieux et pourraient introduire des fonctionnalités d'allègement (tree-shaking). En particulier Webpack 5.