Wie optimiere ich die Größe einer Nuxt.js-basierten Anwendung?

https://httparchive.org/reports/page-weight?start=earliest&end=latest#bytesTotal

Um unser Frontend zu solch großartigen Ergebnissen zu führen, benötigen wir Werkzeuge, die in der Regel in Form von Abhängigkeiten node_modules geliefert werden (wir sprechen hier von einer sehr großen Anzahl von Abhängigkeiten).

Bei der Installation eines Moduls kann es dazu kommen, dass zusätzlich bis zu 20 Module generiert werden (Paketabhängigkeiten). Das führt zu einem derart schnellen Wachstum eines Projektes, dass es nach der Installation der erforderlichen Tools (für Transpilierung, Kompilierung, Tests, Linting) zu fast 1 GB anschwillt. In der Regel wird bei 1 GB die Größe nicht hinterfragt, denn unsere lokalen Computer verfügen über reichlich Festplattenspeicher, und die gelegentliche Installation all dieser Abhängigkeiten stellt für uns kein Problem dar. Während der Computer eines einzelnen Entwicklers dazu in der Lage ist, trifft dies auf eine Continuous Integration nicht zu. Diese Prozesse installieren viel häufiger Abhängigkeiten und teilen zudem Ressourcen mit anderen Projekten, was sich auf den Festplattenspeicher, die Leistung von E/A-Prozessen oder den Zustand der Internetverbindung selbst auswirkt.

Daher sollten wir uns nicht nur um den Endbenutzer Gedanken machen, sondern auch um die Freigabeumgebungen selbst, denn solch große Anwendungsgrößen führen zu einem verlängerten Freigabeprozess und möglicherweise folglich zu Frustration der Entwickler, und ich weiß aus Erfahrung, dass nichts ärgerlicher ist als eine lange Verarbeitung bei der Freigabe kleiner Aktualisierungen.

Es gibt mehrere Möglichkeiten der Optimierung. Wir als Frontend-Entwickler können uns mit dem beschäftigen, was uns am meisten schmerzt:  mit der Anzahl der Abhängigkeiten. In diesem Beitrag erfahren Sie, wie Sie die Anzahl der Pakete node_modules auf ein Minimum reduzieren können, vielleicht sogar auf null?

Lassen Sie uns node_modules loswerden

Am einfachsten ist es, nach der Erstellung der Anwendung nur die Abhängigkeiten zu behalten, die für die Ausführung der Anwendung im Produktionsmodus erforderlich sind. Zu diesem Zweck unterscheiden wir bei den installierten Modulen zwischen Produktionsabhängigkeiten – („dependencies“) und Entwicklungsabhängigkeiten („devDependencies“).

Zur besseren Veranschaulichung der Probleme und Lösungen, die Sie hier kennenlernen werden, betrachten wir ein Nuxt.js-Projekt, das mithilfe von  https://github.com/nuxt/create-nuxt-app erstellt wurde – mit einem zusätzlichen Modul @nuxtjs/pwa.

Schauen wir uns an, wie die Datei package.json aussieht:

Sieht prima aus: 9 Pakete, von denen 3 für den Produktionsbetrieb erforderlich sind. Werfen wir nun einen Blick auf die Größen der Pakete node_modules:

Wir können feststellen, dass bei der Installation eines einfachen Projekts nur 9 Abhängigkeiten benötigt werden, aber in Wirklichkeit erhalten wir weitere 800 Abhängigkeiten obendrauf, was uns etwa 200 MB kostet.  node_modules in Projekten, mit denen wir täglich arbeiten, basieren beispielweise auf dem Mechanismus von mono repositories + yarn workspaces, und die Größe all dieser node_modules-Dateien beträgt im Durchschnitt 800 MB.

Erster Schritt – ausschließlich auf die Produktion bezogene Abhängigkeiten

Wir wissen, dass wir nicht alle Pakete benötigen, um die Anwendung ordnungsgemäß auszuführen. Die „devDependencies“ werden nur benötigt, um das Projekt zu erstellen, also erstellen wir das Projekt und behalten nur die Produktionsabhängigkeiten bei.

„Yarn install --production“ installiert nur Produktionspakete („dependencies“), auch wenn zuvor Entwicklungsabhängigkeiten („devDependencies“) installiert wurden.

Schauen wir uns an, wie unser node_modules-Ordner nach diesem Vorgang aussieht:

Der Modus nuxt build --standalone erlaubt es uns, die Core-Pakete in die resultierende server.js-Datei „hineinzuziehen“, sodass wir potenziell keine weiteren Abhängigkeiten benötigen, um eine Nuxt.js-basierte Anwendung auszuführen. So können wir möglicherweise den Ordner node_modules loswerden.

https://github.com/nuxt/nuxt.js/pull/4661

Leider nur möglicherweise, denn nach dem Entfernen von node_modules müssen Sie die Anwendung immer noch mit dem Befehl „yarn start“ starten, der wiederum das Paket @nuxtjs/cli benötigt. Sie können dieses Problem beheben, indem Sie die Anwendung mit folgendem Befehl starten:

“npx nuxt-start”

Auf diese Weise müssen Sie nicht alle Pakete lokal installieren. Der Befehl “npx” sucht zuerst nach Binärdateien in Ihren lokalen node_modules. Wenn er keine findet, sucht er nach global installierten Modulen, und als letzten Ausweg ruft er npm registry auf, um das betreffende Modul aus dem Internet herunterzuladen.

Mir ist klar, dass der npx-Befehl für die Produktion vielleicht nicht die beste Idee ist. Ohne eine spezifische Versionsdefinition werden Sie immer die neueste Version erhalten oder die Version, die Sie lokal haben. Daher sieht dieser Prozess je nach der von Ihnen verwendeten Bereitstellung möglicherweise anders aus. Wenn Sie Docker verwenden, können Sie eine bestimmte nuxt-start-Version global auf Docker installieren oder ein zusätzliches Skript vorbereiten, das nach dem Erstellen der Anwendung im Standalone-Modus alle node_modules entfernt und dann nur das benötigte nuxt-start-Modul installiert.

Eine Sache, die Sie bei der Entwicklung Ihrer Anwendung beachten sollten, ist die Verwendung von „buildModules” anstelle von „modules“ bei der Definition der Liste der verwendeten Module in nuxt.config.js. Der Unterschied zwischen den beiden besteht darin, dass „buildModules“ immer in den resultierenden Dateien enthalten sind, so dass die Anwendung schneller starten kann und die Größe von node_modules für die Produktionsbereitstellung reduziert wird. Sie müssen in der Dokumentation des zu installierenden Moduls nachsehen, ob es die Option „buildModules“ unterstützt. Mehr dazu finden Sie hier.