Gründe dafür

• Es ist eine neue Version von Nuxt verfügbar (Nuxt 3), die handlicher ist und weniger Konfiguration erfordert
• Für Nuxt 3 ist Vue 3 erforderlich
• Beides verbessert im Laufe der Zeit DX und Wartbarkeit
• Zuletzt und noch wichtiger: Vue 2 wird ab Version 7 nicht mehr unterstützt

• Die Architektur
• Das Problem
• Die Strategie
• Der Workflow
• Andere Überlegungen

Mal sehen, was wir haben:

Dies ist eine ziemlich verbreitete Micro-Frontend-Distribution, die aus drei Schichten besteht:

• Schicht 1 oder Hauptschicht stellt dem Benutzer Module über ein einziges Fenster zur Verfügung.
• Schicht 2 oder Modulschicht enthält verschiedene Domänen oder Module aus unserer Anwendung, Zahlungen, Blogs usw.
• Schicht 3 oder Common Layer ist für die gemeinsame Nutzung von wiederverwendbarem Code innerhalb von Modulen verantwortlich. Hier finden wir zum Beispiel unsere Designsysteme und modulübergreifenden Utilities.

Wir verwenden Module Federation (MF) , um Code zwischen Repositorys mithilfe eines „Remote“- und „Host“ -Musters zu teilen und zu konsumieren, bei dem der Remote- Code verfügbar ist und der Host ihn so verwendet, als käme er von sich selbst.

Das Problem

Obwohl Module Federation ein enormes Potenzial offenbart, bietet es auch eine Schwäche: Es führt uns zu einer eng gekoppelten Mikro-Frontend-Architektur:

Wenn wir eine gemeinsame Abhängigkeit zwischen einem Repository aktualisieren, könnte die gesamte App kaputt gehen

Dies gilt insbesondere dann, wenn wir verschiedene Versionen von Vue verwenden, wenn wir von Version 2 auf Version 3 wechseln.

Die Strategie

Sehen wir uns also die Optionen an, die wir haben:

1. Stellen Sie Komponenten in der Remote-Umgebung als Webkomponenten bereit, damit der Host sie als nativen und Framework-unabhängigen Code erhält.
2. Führen Sie ein Upgrade auf Vue 3 durch und verwenden Sie ein Kompatibilitätspaket, das den darin enthaltenen Vue 2-Code unterstützt.

• Machen Sie es für zukünftige Updates einfacher, die Webkomponentenkonfiguration nicht noch einmal schreiben zu müssen
• ermöglicht das Upgrade von Repositorys in den Schichten 2 und 3 ohne eine bestimmte Reihenfolge
• ermöglicht bei Bedarf die Verwendung verschiedener Frameworks

Hinweis: Vue 3 hat das Stilproblem gelöst und diese Option sollte für zukünftige Upgrades nicht verworfen werden

Allerdings sollte der Prozess in zwei Phasen unterteilt werden:

Bühne 1

Verwenden Sie das Kompatibilitätspaket in jedem Repository von oben bis unten

Stufe 2

Aktualisieren Sie die Repositorys von unten nach oben auf den Vue 3-Stil und entfernen Sie die Kompatibilitätspakete, wenn dies nicht erforderlich ist

Der Workflow

Während wir im Migrationsprozess arbeiten, sollten wir anderen Teams einen kontinuierlichen Arbeitsablauf ermöglichen, damit sie an ihren normalen Aufgaben arbeiten können. Auch hier haben wir zwei Möglichkeiten:

1. Führen Sie die Migration innerhalb des aktuellen Repositorys über einen neuen Zweig durch
2. Erstellen Sie ein neues Repository und migrieren Sie unseren Code schrittweise

Vorteile

• Der Aufbau einer neuen Infrastruktur ist nicht erforderlich, da wir das nutzen, was wir haben

• Wenn andere Teams Funktionen einführen, neigen wir dazu, viel Zeit in die Lösung von Konflikten zu investieren, wenn wir sie in unseren Migrationszweig übertragen
• Wir testen, ob es funktioniert, nur wenn wir am Ende unseren Zweig zusammenführen
• Wir sind von der Arbeit anderer Teams isoliert

Zweiter Ansatz

Vorteile:

• Wenn wir Code in das neue Repository verschieben, entfernen wir ihn aus dem alten und reduzieren so die Anzahl der Konflikte
• Verbessern Sie die Zusammenarbeit: Andere Teams können ihre Aufgaben im neuen Repository erledigen
• Wir stellen schnell sicher, dass unser neues Repository funktioniert, da wir es parallel zum alten verwenden

• erfordert einen Reverse-Proxy, der auf das alte oder das neue Repository verweist
• erfordert den Aufbau einer neuen automatischen Pipeline für das neue Repository
• Entwickler sollten zwei Repositorys für dasselbe Projekt verwenden

In unserem Fall arbeiten mehrere Teams an der gesamten Architektur und wir haben bereits einen Reverse-Proxy implementiert. Der zusätzliche Aufwand würde also darin bestehen, eine neue Pipeline für das neue Repository zu erstellen. Aus diesem Grund ist dies unser Weg.

Andere Überlegungen

Bundler

Wir verwenden Webpack 5 in allen unseren Repositories, aber derzeit gibt es im Internet kaum Informationen darüber, wie es in einer Nuxt 3-App verwendet werden kann. Da Vite die Standardversion ist und eine bessere Entwicklererfahrung bietet, haben wir uns für diese entschieden.

Aktualisierung der Knotenversion

Wir verwenden derzeit Node 14, aber Nuxt und Vue 3 erfordern Version 16 oder höher, wir werden Version 18 verwenden.

Schlussfolgerungen

Da wir ein mittelgroßes Team sind und viele Abhängigkeiten innerhalb unserer App nutzen, entscheiden wir uns für Folgendes:

1. Verwenden Sie ein Kompatibilitätspaket, um unseren Code zu aktualisieren
2. Erstellen Sie neue Repositorys für eine schrittweise und gemeinsame Migration
3. Aktualisieren Sie dabei unsere Knotenversion und ersetzen Sie Webpack durch Vite

• Vuemastery – Vue 3 Migration Build
• fingo – Strangler Pattern: So erwürgen Sie Ihr Altsystem
• harlanzw – Nuxt 3-Migration vereinfacht: Spickzettel
• Nuxt 3 – Erste Schritte
• Nuxt 3 – Leitfaden
• Nuxt 3 – API
• Vue 3 – Migrations-Build

Das Open-Source-Tool von Bit hilft mehr als 250.000 Entwicklern beim Erstellen von Apps mit Komponenten.

Verwandeln Sie jede Benutzeroberfläche, Funktion oder Seite in eine wiederverwendbare Komponente – und teilen Sie sie in Ihren Anwendungen. Es ist einfacher, zusammenzuarbeiten und schneller zu erstellen.

→ Erfahren Sie mehr

Teilen Sie Apps in Komponenten auf, um die App-Entwicklung zu vereinfachen, und genießen Sie das beste Erlebnis für die von Ihnen gewünschten Arbeitsabläufe:

→ Micro-Frontends

→ Designsystem

→ Code-Sharing und Wiederverwendung

→ Monorepo

Erfahren Sie mehr: