Es ist nur allzu leicht, mit den Importen verrückt zu werden und am Ende Megabytes an JavaScript zu haben. Es kann ein Problem sein, da dieses Gewicht jeden einzelnen Besucher unserer Website belastet und ihn sehr gut davon abhalten kann, das zu tun, wofür er auf die Website gekommen ist. Schlecht für sie, schlimmer für Sie.
Es gibt alle möglichen Wege, um es im Auge zu behalten.
Sie könnten einen Blick auf Bundlephobia werfen
Bundlephobia gibt Ihnen einen Überblick über die Gesamtgröße – sowohl komprimiert als auch unkomprimiert –, zusammen mit Downloadzeiten, der Anzahl der erforderlichen Unterabhängigkeiten und ob es tree-shakbar (tree-shook? tree-shaken?) ist.
Wo wir gerade von "Phobie" sprechen, gibt es auch Package Phobia, das die Upload- und Installationsgrößen einzelner Pakete anzeigt.
Sie könnten VS Code dazu bringen, es Ihnen direkt im Editor anzuzeigen.
Ihre Import- und Require-Anweisungen können Ihnen die Größe dieser speziellen Einbindung mit der Import Cost-Erweiterung anzeigen.
Sie könnten sich eine Datenvisualisierung ansehen
Der Webpack Bundle Analyzer macht das.
Sie könnten sich die Größen mit Textausgabe ansehen
Cost of modules ist ein weiterer Analyzer, aber er scheint nur `package.json` zu betrachten und nicht den fertigen Bundle, dann gibt er ihn als Tabelle aus.
Webpack Bundle Size Analyzer zeigt Ihnen eine verschachtelte Liste von Abhängigkeitsgrößen an, einschließlich der Größe des Bundle-Codes selbst, was interessant ist.
package size zeigt Ihnen das Gewicht einer durch Kommas getrennten Liste von Paketen an.
package size hat eine einfache CLI-Syntax dafür.
Haben Sie eine andere bevorzugte Methode, um Ihr Projekt im Griff zu behalten?
Ich benutze https://github.com/siddharthkp/bundlesize und Continuous Integration, sodass der Build fehlschlägt, wenn das Bundle zu groß ist.
Der beste Weg ist, native APIs zu lernen und zu lernen, wie man tatsächlich programmiert, anstatt Bibliotheken für alles in Ihrer App zu verwenden. ;)
Ich weiß, dass Sie dort ein kleines Zwinkergesicht hatten, also ist das wahrscheinlich leicht augenzwinkernd gemeint. Und ich verstehe die Meinung, dass es vielleicht ein wenig zu viel gibt, um Probleme mit npm-install zu lösen, auf Kosten des Nutzers.
Aber ich wäre vorsichtig mit dieser "Lerne, wie man tatsächlich programmiert"-Einstellung. Sie wirkt etwas stolz und könnte einen Anfänger auf eine Weise beschämen, die er wirklich nicht braucht.
Außerdem – Achtung bei diesem SSL-Zertifikat.
Seltsamer Gedanke, ich dachte immer, man sollte niemals sein eigenes Fahrrad erfinden, wenn es bereits eines gibt.
Erfinde das Rad nicht neu, aber wähle die passende Reisemethode je nach Entfernung und verfügbarer Zeit: zu Fuß (nativer Code), Fahrrad (winzige Abhängigkeit) oder etwas Größeres – Auto, Zug, Flugzeug (großer Bundle).
Danke, Chris. Bundle-Größen und Abhängigkeiten werden viel zu oft übersehen. Danke für die Erinnerung. Ich habe den visuellen Bundle-Analyzer schon einmal benutzt, kannte aber die anderen nicht. Danke fürs Teilen!
Sie können dies auch in einem Pre-Commit-Hook automatisieren.
( `lint-staged` wird verwendet, um committete Dateien zu filtern.)
In `package.json` konfigurieren Sie den Pre-Commit-Hook so, dass er `lint-stagged` auslöst.
Dann konfigurieren Sie lint-staged (ich benutze die `.lintstagedrc`-Datei).
Und schließlich können Sie in `package.json` Ihre Bundle-Größe konfigurieren.
Dieses Rezept funktioniert nur, wenn Sie Ihren `_dist`-Ordner committen.
Aber Sie sollten es leicht anpassen können.