SingleSPA funziona. Le import map non si gestiscono da sole
SingleSPA funziona. Eseguiamo app React, Vue e Angular su una singola pagina. Si caricano in modo indipendente. Il framework fa il suo dovere.
Il problema non è il framework. Il problema è l'ecosistema che lo circonda.
In un'architettura distribuita, serve la ownership. Serve l'auditing. Serve la governance. SingleSPA rende visibili queste necessità perché l'import map è un punto centrale di coordinamento.
L'import map risiede nella vostra root config. È un file JSON. Dice a ogni micro frontend (MFE) quale versione di React caricare. In teoria, è la source of truth. In pratica, nessuno ne è responsabile.
Ogni team è responsabile del proprio MFE. Nessuno è responsabile della mappa.
Questo crea problemi:
- I team dismettono un MFE, ma la voce rimane nella mappa.
- Appaiono nuove dipendenze, ma nessuno le aggiunge alla mappa.
- La mappa si deteriora mentre viene ignorata.
Abbiamo trovato un MFE nella nostra mappa che non veniva distribuito da otto mesi. Era morto, ma veniva ancora caricato in produzione. Nessuno se n'è accorto perché nessuno stava controllando.
Potreste pensare di generare automaticamente la mappa durante la build. Ci abbiamo provato. Crea un nuovo problema: i conflitti di merge. Se quattordici team cercano tutti di scrivere in un unico file JSON durante ogni deploy, la vostra pipeline CI diventa un caos.
Un altro problema è il drift. Il pattern è semplice: segnate React come external nella vostra config. Lasciate che sia l'import map a servirlo. Questo evita bundle duplicati.
Ma poi qualcuno rifattorizza il proprio codice. Per errore, includono nuovamente React nel bundle del proprio MFE. La build passa. I test passano. Il deploy è verde.
Ve ne accorgete solo quando:
- Le dimensioni dei bundle aumentano improvvisamente.
- Un mismatch di versioni rompe un componente.
- Vedete React caricarsi due volte in Chrome DevTools.
Abbiamo effettuato un audit del nostro sistema e abbiamo trovato due MFE che distribuivano il proprio React. Le loro build erano verdi. Non avevano idea di non essere conformi.
L'import map e i vostri file package.json sono due input separati. Si allontanano silenziosamente l'uno dall'altro.
Un controllo CI può trovare bundle duplicati. Non può trovare mismatch di versioni. Se l'MFE A usa React 18.2 e l'MFE B usa la 18.3, la build non fallirà. Ma i vostri componenti condivisi si romperanno a runtime.
Quando dobbiamo aggiornare React, passiamo ore a fare grep attraverso quattordici repository diversi. È inefficiente.
Abbiamo costruito uno strumento per risolvere questo problema. Fa due cose:
- Crea una matrice di versioni partendo dal
package.jsondi ogni MFE. - Confronta tale matrice con la vostra import map.
Lo strumento vi mostra il divario. Vi mostra quali team sono conformi e quali si sono discostati. Trova anche voci obsolete e URL interrotti. Lo eseguiamo ogni lunedì mattina. Ci mette 12 secondi.
La nostra lezione non è stata tecnica. Ogni architettura distribuita ha bisogno di un proprietario per l'infrastruttura condivisa. In SingleSPA, l'import map è infrastruttura. Non trattatela come un file condiviso. Trattatela come un asset gestito.
Voi come gestite la cosa? Avete un proprietario dell'import map? O passate i vostri lunedì mattina a fare grep sui file?
Fonte: https://dev.to/siongsheng/singlespa-works-import-maps-dont-manage-themselves-4jbe