Retour d’expérience sur le débogage frontend de Cashnote — « Chez moi, ça marchait pourtant… »
(spilist.notion.site)Retour d’expérience sur le débogage de 3 problèmes CSS rencontrés ces derniers mois par l’équipe frontend de Cashnote (https://cashnote.kr) dans l’exploitation d’un produit React
- Ils ont tous en commun d’avoir été découverts en production, alors qu’ils n’avaient pas été observés en environnement de développement, avec
create-react-appet l’utilisation de CSS Modules
Problème 1 : après être entré sur une page spécifique, les images se déforment sur toutes les pages
-
La cause était une définition de style CSS sous une forme que CSS Modules ne pouvait pas hasher
-
Le problème a été résolu en ajoutant un plugin stylelint pour empêcher la définition de ce type de style
Problème 2 : le rendu des styles CSS diffère entre l’environnement de développement et l’environnement de production
-
Un composant spécifique surchargeait le style d’un composant du design system, mais en production, le CSS du composant du design system était injecté plus tard, ce qui empêchait la surcharge de s’appliquer
-
Le problème a d’abord été résolu en modifiant la configuration Webpack, mais cette décision sacrifiait les performances en production et n’était pas satisfaisante
-
En cherchant une autre méthode, l’équipe a découvert qu’un changement de configuration du bundler (
rollup) côté design system permettait la surcharge. Le CSS injecté par le design system a donc été modifié pour être toujours placé en haut de la balisehead
Problème 3 : tout fonctionne en développement, mais le build de production échoue
-
Lors de la création des CSS Chunks par un plugin Webpack, le build de production échouait à cause d’un avertissement indiquant que deux fichiers CSS étaient importés dans un ordre différent, ce qui pouvait produire des résultats de style différents dans les deux chunks
-
Comme Cashnote utilise CSS Modules, chaque fichier CSS fonctionne indépendamment ; ce conflit d’ordre ne produisait donc pas de résultat de style différent. La configuration Webpack a donc été modifiée pour ignorer cet avertissement
Les deux derniers problèmes avaient des symptômes de surface différents, mais se ressemblaient en ce qu’ils provenaient tous deux d’un « manque de compréhension de la façon dont le framework frontend create-react-app fonctionne en environnement de production »
- Pour une amélioration de fond, l’équipe cherche à mieux comprendre CRA et Webpack, et se prépare plus largement à se passer de CRA
2 commentaires
Merci pour ce partage d’expérience intéressant. Comme toujours, tout fonctionne parfaitement en local !
Merci. Résumer brièvement l’article n’est pas si simple non plus, haha.