Les gars, aujourd'hui on ne parle pas de choses vagues, je vais vous raconter un gros piège dans lequel je suis tombé ces deux derniers jours, et comment j'en suis sorti. Voilà, on a un ancien projet en ligne qui tournait bien, mais récemment les utilisateurs ont signalé des pages blanches occasionnelles. Le taux d'erreurs n'était pas élevé, mais vu le grand nombre d'utilisateurs, je recevais des tas de journaux d'erreurs dans ma boîte mail chaque jour. Au début, j'ai pensé que c'était un problème côté backend, j'ai cherché longtemps sans rien trouver. Puis j'ai regardé la surveillance front-end et j'ai été stupéfait : c'étaient toutes des erreurs JS, et elles étaient toutes concentrées dans le fichier bundle minifié.
Vous savez, en production, le JS est minifié, avec des lignes de dizaines de milliers de caractères, les messages d'erreur sont illisibles. J'ai fixé ce « Unexpected token » pendant un long moment, j'avais l'impression qu'il se moquait de moi. Finalement, j'ai activé les sourcemaps pour localiser, et j'ai découvert que les erreurs étaient variées, mais avaient un point commun : c'étaient toutes du code écrit dans des conditions, ou utilisant la syntaxe ES6+.
C'est là que j'ai réalisé que le problème venait peut-être de la configuration de minification. L'outil de minification qu'on utilise est assez ancien, et à l'époque, pour simplifier, on avait utilisé la configuration par défaut sans regarder en détail. Certaines options d'optimisation par défaut, comme « drop_debugger » ou les trucs dans « compress », sont un désastre pour l'ancien code.
Je vais vous donner l'exemple le plus typique : l'outil de minification supprime par défaut les branches conditionnelles qu'il considère comme « toujours fausses ». Par exemple, si vous écrivez if (typeof window !== 'undefined') pour supporter le SSR ou éviter des erreurs dans certains environnements spéciaux, le minificateur considère que c'est inutile, car il analyse le contexte et pense que window existe forcément, donc il supprime tout le bloc if. Résultat ? Sur de vrais appareils, dans certains environnements WebView, certaines propriétés de window ne sont pas accessibles, et le code plante directement.
Il y a un autre piège : le minificateur raccourcit les noms de variables dans les fonctions, par exemple userName devient a, orderList devient b. La plupart du temps, ça ne pose pas de problème, mais si votre code utilise eval ou new Function qui référencent des noms de variables externes, après minification les noms ne correspondent plus, et vous obtenez une erreur ReferenceError. On a quelques anciens modules en ligne qui utilisent ça, ça marche normalement, mais une fois minifié, ça casse.
Donc ces deux derniers jours, j'ai pris une décision : j'ai passé un après-midi entier à étudier cette configuration de minification. Après l'avoir modifiée, devinez quoi ? Les erreurs en ligne ont chuté de 80 % ! Ce n'est pas de la magie, c'est juste que la configuration n'était pas bonne.
Voici précisément ce que j'ai modifié, vous pouvez prendre des notes, ça pourrait vous sauver un jour :
Premièrement, j'ai désactivé conditionals et dead_code dans l'option compress. C'est pour l'empêcher de supprimer intelligemment des branches de code. Bien sûr, le taux de compression diminue un peu, peut-être quelques Ko en plus, mais ça vaut le coup pour la stabilité ! Surtout pour les anciens projets pleins de vérifications de compatibilité, ces deux options sont des bombes à retardement.
Deuxièmement, j'ai mis eval à true dans mangle. Cela signifie que si le code contient eval ou new Function, il ne modifiera pas les noms de variables à l'intérieur, ou du moins ne raccourcira pas ces variables. L'effet de compression sera moindre, mais c'est mieux que de voir le site planter.
Troisièmement, j'ai aussi désactivé unused dans compress. Cette option supprime les paramètres « définis mais non utilisés ». Mais parfois, on garde volontairement un paramètre comme placeholder, par exemple dans les fonctions de rappel, où le troisième paramètre est utile, les deux premiers étant une signature fixe. Le minificateur ne le sait pas, il voit que les deux premiers ne sont pas utilisés et les supprime, ce qui décale les paramètres du rappel, et quand on les appelle, on reçoit undefined, et toute la logique est faussée.
Quatrièmement, et c'est le plus souvent négligé, c'est le paramètre ascii_only dans output. Si votre code contient des chaînes en chinois ou des emojis, je recommande de le mettre à false, sinon tout sera converti en séquences d'échappement comme \uXXXX. La fonctionnalité est la même, mais la longueur des chaînes explose, et certains anciens navigateurs ont des problèmes avec les chaînes trop longues, ce qui peut provoquer des blocages ou des erreurs.
Bref, ma configuration actuelle, c'est le mode « ne vous mêlez pas de ce qui ne vous regarde pas ». Le but de la minification est de réduire la taille, mais si pour réduire la taille on casse les fonctionnalités, alors les quelques Ko économisés ne valent pas les heures supplémentaires. J'ai calculé : après modification, la taille du fichier packagé n'a augmenté que d'environ 15 %, mais le taux d'erreurs en ligne est passé de plusieurs centaines par jour à quelques unités par jour. Ces quelques Ko, on s'en fiche.
Enfin, un conseil : après avoir modifié la configuration de minification, il faut absolument exécuter une suite complète de tests de régression, surtout pour les parties qui utilisent le chargement paresseux des routes ou les importations dynamiques. Ne me demandez pas pourquoi je sais ça, j'en ai pleuré. En tout cas, maintenant le site est stable, et je peux dormir tranquille. Si vous avez des problèmes similaires, ne remettez pas en cause la logique du code, vérifiez d'abord si votre configuration de minification ne vous joue pas des tours.