Motivi

• È disponibile una nuova versione di Nuxt (Nuxt 3) che è più maneggevole e richiede meno configurazioni
• Nuxt 3 richiede Vue 3
• Entrambi migliorano la DX e la manutenibilità nel tempo
• Ultimo e più importante: Vue 2 non riceverà più supporto dalla versione 7

• L'architettura
• Il problema
• La Strategia
• Il flusso di lavoro
• altre considerazioni

Vediamo cosa abbiamo:

Questa è una distribuzione micro-frontend piuttosto comune, composta da 3 livelli:

• Il livello 1 o livello principale espone i moduli all'utente attraverso un'unica finestra.
• Layer 2 o Module Layer contiene diversi domini o moduli della nostra applicazione, pagamenti, blog e così via.
• Layer 3 o Common Layer è responsabile della condivisione del codice riutilizzabile all'interno dei moduli. Qui possiamo trovare, ad esempio, i nostri sistemi di progettazione e le utilità cross-module.

Utilizziamo Module Federation (MF) , per condividere e consumare codice tra repository utilizzando un modello "remoto" e "host" in cui il telecomando espone il codice e l' host lo utilizza come se provenisse da se stesso.

Il problema

Sebbene Module Federation riveli un enorme potenziale, offre anche un punto debole: ci porta a un'architettura micro-frontend strettamente accoppiata:

Se aggiorniamo una dipendenza comune tra qualsiasi repository potremmo rompere l'intera app

Questo è vero soprattutto quando si utilizzano versioni diverse di Vue mentre si passa dalla versione 2 alla versione 3.

La Strategia

Quindi vediamo le opzioni che abbiamo:

1. Esponi i componenti nel telecomando come componenti Web, in modo che l'host li riceva come codice nativo e indipendente dal framework.
2. Esegui l'upgrade a Vue 3 e usa un pacchetto di compatibilità che supporti il ​​codice Vue 2 al suo interno.

• rendere più semplice per gli aggiornamenti futuri non dover scrivere nuovamente la configurazione del componente Web
• consente di aggiornare i repository nei livelli 2 e 3 senza un ordine specifico
• consente di utilizzare diversi framework se necessario

Nota: Vue 3 ha risolto il problema degli stili e questa opzione non dovrebbe essere scartata per futuri aggiornamenti

Detto questo, il processo dovrebbe essere diviso in 2 fasi:

Fase 1

Usa il pacchetto di compatibilità in ogni repository dall'alto verso il basso

Fase 2

Aggiorna i repository dal basso verso l'alto allo stile Vue 3 e rimuovi i pacchetti di compatibilità una volta che non è richiesto

Il flusso di lavoro

Allo stesso tempo, lavoriamo nel processo di migrazione, dovremmo consentire un flusso di lavoro continuo affinché altri team lavorino sulle loro normali attività, ancora una volta abbiamo 2 opzioni:

1. effettuare la migrazione all'interno del repository corrente tramite un nuovo ramo
2. creare un nuovo repository e migrare progressivamente il nostro codice

Vantaggi

• Non richiede la costruzione di una nuova infrastruttura perché stiamo usando quello che abbiamo

• man mano che altri team introducono funzionalità, siamo inclini a investire una discreta quantità di tempo nella risoluzione dei conflitti quando li trasferiamo nel nostro ramo di migrazione
• testiamo se funziona solo quando uniamo il nostro ramo alla fine
• siamo isolati dal lavoro dell'altra squadra

Secondo approccio

Vantaggi:

• quando spostiamo il codice nel nuovo repository lo rimuoviamo da quello vecchio riducendo il numero di conflitti
• aumentare la collaborazione: altri team possono svolgere i propri compiti nel nuovo repository
• ci assicuriamo rapidamente che il nostro nuovo repository funzioni perché lo stiamo utilizzando in parallelo con quello vecchio

• richiede che un proxy inverso punti al vecchio o al nuovo repository
• richiede la creazione di una nuova pipeline automatica per il nuovo repository
• gli sviluppatori dovrebbero utilizzare 2 repository per lo stesso progetto

Nel nostro caso, siamo più team che lavorano sull'intera architettura e abbiamo già implementato un proxy inverso, quindi lo sforzo aggiuntivo consisterebbe nella creazione di una nuova pipeline per il nuovo repository e, per questo motivo, questa è la nostra strada da percorrere.

altre considerazioni

Bundler

Usiamo Webpack 5 in tutti i nostri repository ma in questo momento le informazioni sul web sono scarse su come usarlo in un'app Nuxt 3. Poiché Vite è l'impostazione predefinita e offre una migliore esperienza per gli sviluppatori, scegliamo questa.

Aggiornamento della versione del nodo

Attualmente stiamo utilizzando Node 14 ma Nuxt e Vue 3 richiedono la versione 16 o successiva, useremo la versione 18.

Conclusioni

Poiché siamo un team di medie dimensioni e utilizziamo molte dipendenze all'interno della nostra app, decidiamo di:

1. Usa un pacchetto di compatibilità per aggiornare il nostro codice
2. Crea nuovi repository per migrare progressivamente e in modo collaborativo
3. Nel processo aggiorna la nostra versione del nodo e sostituisci Webpack con Vite

• Vuemastery — Build di migrazione di Vue 3
• fingo — Strangler Pattern: come strangolare il tuo sistema legacy
• harlanzw — Nuxt 3 Migration Semplified: Cheat Sheet
• Nuxt 3 — Inizia
• Nuxt 3 — Guida
• Nuxt 3 — API
• Vue 3 — Build di migrazione

Lo strumento open source di Bit aiuta oltre 250.000 sviluppatori a creare app con componenti.

Trasforma qualsiasi interfaccia utente, funzionalità o pagina in un componente riutilizzabile e condividilo tra le tue applicazioni. È più facile collaborare e costruire più velocemente.

→ Ulteriori informazioni

Dividi le app in componenti per semplificare lo sviluppo delle app e goditi la migliore esperienza per i flussi di lavoro che desideri:

→ Micro-Frontend

→ Sistema di progettazione

→ Code-sharing e riuso

→ Monorepo

Saperne di più: