Votre bundle de production a pris quatre cents kilooctets après la fusion d'une fonctionnalité. Comment gérez-vous ça ?

Comparez les bundles au lieu de deviner. Lancez un analyseur de bundle sur le commit d'avant et sur celui d'après, et cherchez une nouvelle dépendance, une version dupliquée d'une dépendance existante, ou un import barrel qui tire toute une bibliothèque. Corrigez avec une dépendance plus légère, des imports profonds, ou un import dynamique si le code n'est pas nécessaire au premier affichage. Ajoutez ensuite un budget de taille en CI pour que ça ne puisse plus arriver en silence.

D'abord je récupère les faits. Je construis le commit précédent et le courant et je passe un analyseur sur les deux, comme ça je peux pointer le module exact qui a grossi au lieu d'en débattre. En général c'est l'une de trois choses. Quelqu'un a ajouté une grosse dépendance pour une seule fonction, une bibliothèque de dates ou d'utilitaires étant le classique. Ou on livre maintenant deux versions du même paquet parce qu'une dépendance transitive en a épinglé une autre, ce que l'analyseur montre sous forme de morceaux dupliqués. Ou un fichier index réexporte tout et le tree shaking a abandonné parce que le paquet n'est pas marqué sans effets de bord. Le correctif suit la cause : remplacer par une dépendance plus légère ou l'équivalent de la plateforme, dédupliquer la version, ou importer le chemin de module précis. Si le code est vraiment nécessaire mais pas au premier affichage, comme un éditeur de texte riche ou une bibliothèque de graphiques, il devient un import dynamique derrière l'interaction qui en a besoin. Ensuite j'ajoute en CI un budget de taille qui fait échouer la pull request sur un saut pareil, parce que sinon ça se reproduit au trimestre suivant.