Es gibt viele Webpack-Pakete, die Duplikate im Bundle finden. Das beliebteste davon ist das Duplicate-Package-Checker-Webpack-Plugin. Das Projekt muss jedoch neu zusammengesetzt werden. Da die Auswahl der optimalen Version von Paketen automatisiert werden musste, stellte sich heraus, dass es sich um eine eigene alternative Lösung handelt.
Nun, oder meine Geschichte ist, wie sich herausstellte, dass das Bündel in wenigen Sekunden um 15% reduziert wurde.
Wie in vielen großen Unternehmen mit einer riesigen Codebasis gibt es viele gemeinsame Logiken. Daher verwenden wir gemeinsame Komponenten, die in unserem npm-Repository veröffentlicht sind. Sie werden vor jeder Installation oder Aktualisierung allgemeiner Komponenten über lerna veröffentlicht. Es stellt sich die Frage, welche Version installiert werden soll. lerna überschreibt alle Komponenten, die die veröffentlichte Komponente verwenden (wenn die Version zuvor die neueste war). Dementsprechend gibt es immer Versionen mehrerer Komponenten, die besser zueinander passen, da sie nicht mit Abhängigkeiten konkurrieren.
Von Open-Source-Projekten auf diese Weise nivo , hier ist ihre lerna-Konfiguration .
Wie erscheinen dann doppelte Abhängigkeiten? Und wie kann man sie beseitigen?
Angenommen, Sie haben ein einfaches Projekt mit der folgenden package.json :
{ "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" } }
Mal sehen, wo @nivo/core :
npm list @nivo/core
Wir sehen 4 Kopien von @nivo/core (3 Kopien von 0.54.0 und 1 - 0.53.0 ). Wenn wir jedoch die Nebenversion von @nivo/core auf 0.54.0 , werden Duplikate entfernt.
Das aktuelle Beispiel ist einfach, aber in der Praxis hat natürlich jedes Paket mehr Abhängigkeiten, und Sie müssen die Abhängigkeiten noch weiter berücksichtigen, was die Komplexität der Aufgabe erhöht.
Und als ich wieder einmal die enorme Größe des Bundles sah, war ich es leid, doppelte Pakete manuell zu entfernen.
Im Allgemeinen ist es richtig, Pakete sofort auf die neueste Version zu aktualisieren, aber es bleibt wie immer keine Zeit, Hauptversionen zu ändern, und es ist lang und schwierig, das entsprechende Paket blind auszuwählen. Schließlich müssen Sie die Abhängigkeitsversion in package.json , neue Abhängigkeiten installieren und dann überprüfen, ob Duplikate im Build verschwunden sind. Wenn nicht, wiederholen Sie dies für eine lange Zeit, durchschnittlich 3-4 Minuten pro Iteration.
All dies ist eintönig und erfordert Aufmerksamkeit, deshalb habe ich mich für die Automatisierung entschieden.
Ich möchte Duplikate kennen, ohne Abhängigkeiten neu zu installieren und das Projekt neu zu erstellen, idealerweise eine CLI-Anwendung, die Optimierungsoptionen in 10 Sekunden und alle vorhandenen Duplikate im Projekt anzeigt.
Die Eliminierung von Takes kann in mehrere Unteraufgaben unterteilt werden, wir werden sie der Reihe nach betrachten.
Erste Aufgabe. Sie müssen den zukünftigen Bundle-Abhängigkeitsbaum nur mit package.json modellieren, da die Standard-Deduplizierung schnell und in nicht mehr als 100 ms erfolgt.
Ich entschied mich für package-json , um Informationen zu Paketen zu erhalten, und für semver , um verschiedene Versionen zu vergleichen.
Das Ergebnis war ein npm - Paketabhängigkeitsbaum -Builder , der den Bundle-Abhängigkeitsbaum nur von package.json intelligent modellierte.
Wird einer separaten Komponente zugewiesen, da sie möglicherweise von jemandem in kombinatorischen Aufgaben mit package.json wiederverwendet wird.
Die zweite Aufgabe. Eine kombinatorische Aufgabe, eine effiziente Aufzählung von Optionen zum Ändern von Abhängigkeiten und ein Vergleich mehrerer Optionen für Bäume und natürlich die Auswahl der optimalen.
Es war notwendig, die resultierenden Bäume irgendwie qualitativ zu vergleichen, und wir mussten die Idee der Entropie ausleihen, als quantitatives Maß für die Störung, die Summe der doppelten Kopien (aus dem obigen Beispiel ist es 3).
Es wäre toll, Paketgewichte zu berücksichtigen (in KB), aber leider habe ich kein Paket gefunden, das schnell mit Gewichten funktioniert, und solche, die ungefähr eine halbe Minute pro Paket funktionieren, zum Beispiel Paketgröße . Da sie nach dem folgenden Prinzip arbeiten: Erstellen Sie ein Projekt mit einer einzelnen Abhängigkeit, stellen Sie Abhängigkeiten her, wonach das Gesamtgewicht des Ordners gemessen wird. Infolgedessen habe ich mir kein anderes Kriterium ausgedacht, nämlich die Anzahl der Kopien.
Um zu verstehen, welches Paket geändert werden muss, werden die Gründe für Duplikate, insbesondere die Quelle und der Effekt, berücksichtigt. Durch die Aufzählung werden doppelte Effekte so weit wie möglich eliminiert. Da die Effekte eliminiert werden, werden sie später auch dupliziert.
Als Ergebnis haben wir eine kleine Cli-Ostap-Anwendung erhalten, die optimale Versionen zur Reduzierung der Anzahl doppelter Instanzen im Bundle empfiehlt.
Es beginnt damit, dass Sie auf package.json Ihres Projekts zeigen.
ostap ./package.json
Sie können es auch verwenden, um alle zukünftigen Takes schnell anzuzeigen, ohne das Projekt neu zu erstellen, indem Sie nur die Versionen in package.json ändern.
ostap ./package.json -s
Infolgedessen verringerte sich in meinem Projekt das Gesamtgewicht der Bündel um 15%.
Das Repository verfügt über einen Schnellstartbereich.
Wenn Sie die Routenaufteilung verwenden, scheint es, dass einige Bundles an Gewicht zugenommen haben, aber die Verteilung der Komponenten hat sich möglicherweise geändert. Das heißt, anstelle von Kopien von Abhängigkeiten auf jeder Seite wurde die einzige Version zu einem gemeinsamen Bundle für alle Seiten. Sie müssen also das Gesamtgewicht der Bundles für alle Seiten bewerten.
Hoffe der Artikel war hilfreich. Und jemand wird Zeitinformationen sparen. Vielen Dank.
Referenzen zur Vereinfachung noch einmal:
- Paketmodellierung des Bundle-Abhängigkeitsbaums durch package.json
Github - Abhängigkeitsoptimierer zum Entfernen von Duplikaten in einem Bundle
Github
Wenn Sie interessante Ideen haben, schreiben Sie an github, wir werden darüber diskutieren.