Il existe de nombreux packages de webpack qui trouvent des doublons dans le bundle, le plus populaire d'entre eux est duplicate-package-checker-webpack-plugin , mais cela nécessite de réassembler le projet, et comme il y avait une tâche pour automatiser la sélection de la version optimale des packages, il s'est avéré sa propre solution alternative.
Eh bien, ou mon histoire est de savoir comment il s'est avéré réduire le forfait de 15%, en quelques secondes.
Comme dans de nombreuses grandes entreprises qui ont une énorme base de code, il y a beaucoup de logique commune, par conséquent, nous utilisons des composants communs publiés dans notre référentiel npm. Ils sont publiés via lerna , respectivement, avant chaque installation ou mise à jour de composants communs, la question se pose de savoir quelle version installer. lerna remplace tous les composants qui utilisent le composant publié (si la version était précédemment la plus récente). En conséquence, il existe toujours des versions de plusieurs composants qui sont mieux adaptées les unes aux autres, car elles ne sont pas en concurrence avec les dépendances.
De projets open source de cette façon nivo , voici leur configuration lerna .
Comment apparaissent alors les dépendances en double? Et comment les éliminer?
Supposons que vous ayez un projet simple avec le package.json suivant:
{ "name": "demo-project", "version": "1.0.0", "dependencies": { "@nivo/bar": "0.54.0", "@nivo/core": "0.53.0", "@nivo/pie": "0.54.0", "@nivo/stream": "0.54.0" } }
Voyons où @nivo/core :
npm list @nivo/core
Nous voyons 4 copies de @nivo/core (3 copies de 0.54.0 et 1 - 0.53.0 ). Mais si nous changeons la version mineure de @nivo/core en 0.54.0 , les doublons seront éliminés.
L'exemple actuel est simple, mais dans la pratique, bien sûr, chaque package a plus de dépendances, et vous devez toujours considérer les dépendances plus loin, ce qui augmente la complexité de la tâche.
Et une fois de plus, voyant la taille énorme du paquet, j'étais fatigué de supprimer manuellement les paquets en double.
En général, il est juste de mettre immédiatement à niveau les packages vers la dernière version, mais il n’y a pas le temps, comme toujours, de changer les versions majeures, et il est long et difficile de sélectionner aveuglément le package approprié. Après tout, vous devez mettre à jour la version des dépendances dans package.json , installer de nouvelles dépendances, puis vérifier si les doublons ont disparu dans la génération, sinon, répéter, pendant longtemps, en moyenne, 3-4 minutes par itération.
Tout cela est monotone et nécessite de l'attention, j'ai donc décidé d'automatiser.
Je voudrais connaître les doublons sans réinstaller les dépendances et reconstruire le projet, idéalement une application cli qui affiche les options d'optimisation en 10 secondes et tous les doublons existants dans le projet.
L'élimination des prises peut être divisée en plusieurs sous-tâches, nous les considérerons dans l'ordre.
Première tâche. Vous devez modéliser la future arborescence de dépendance des bundles uniquement par package.json, compte tenu de la déduplication standard, rapidement, en moins de 100 ms.
J'ai décidé d'utiliser package-json pour obtenir des informations sur les packages et semver pour comparer différentes versions.
Le résultat a été un générateur de dépendances d'arborescence de packages npm, modélisant intelligemment l'arborescence de dépendances de bundles uniquement par package.json.
Alloué à un composant distinct, car peut-être que quelqu'un le réutilisera dans des tâches combinatoires avec package.json.
La deuxième tâche. Une tâche combinatoire, une énumération efficace des options pour changer les dépendances, et une comparaison de plusieurs options pour les arbres, et bien sûr, le choix de l'optimale.
Nous avons dû en quelque sorte comparer qualitativement les arbres résultants, et nous avons dû emprunter l'idée de l'entropie, en tant que mesure quantitative du désordre, a pris la somme des copies en double (de l'exemple ci-dessus il est de 3).
Ce serait formidable de prendre en compte les poids des packages (en Ko), mais malheureusement, je n'ai pas trouvé de package qui fonctionnerait rapidement avec des poids, et ceux qui fonctionnent pendant environ une demi-minute par package, par exemple la taille du package . Puisqu'ils fonctionnent selon le principe suivant: créer un projet avec une seule dépendance, établir des dépendances, après quoi le poids total du dossier est mesuré. Par conséquent, je n'ai pas proposé un autre critère, comme le nombre d'exemplaires en double.
Pour comprendre quel package doit être modifié, les raisons des doublons, plus précisément la source et l'effet, sont prises en compte. L'énumération élimine autant que possible les effets en double et, comme les effets sont éliminés, les doublons sont également effectués plus tard.
En conséquence , nous avons obtenu une petite application cli ostap qui recommande des versions optimales pour réduire le nombre d'instances en double dans le bundle.
Il commence simplement par pointer vers package.json de votre projet.
ostap ./package.json
Vous pouvez également l'utiliser pour afficher rapidement toutes les prises futures sans reconstruire le projet en modifiant uniquement les versions dans package.json.
ostap ./package.json -s
En conséquence, dans mon projet, le poids total des faisceaux a diminué de 15%.
Le référentiel a une section de démarrage rapide.
Si vous utilisez le fractionnement de route, il peut sembler que certains faisceaux ont augmenté de poids, mais la distribution des composants peut avoir changé. Autrement dit, au lieu de copies de dépendances sur chaque page, la seule version s'est transformée en un ensemble commun pour toutes les pages, vous devez donc évaluer le poids total des ensembles pour toutes les pages.
J'espère que l'article vous a été utile. Et quelqu'un économisera des informations de temps. Je vous remercie
Références pour plus de commodité:
- Package modélisant l'arborescence de dépendance des bundles par package.json
Github - Dependency Optimizer pour éliminer les doublons dans un bundle
Github
Si vous avez des idées intéressantes, écrivez pour publier sur github, nous en discuterons.