Quando Webpack raggruppa i tuoi moduli segue la catena di dipendenze del modulo che hai importato (o richiesto) e estrae tutte le sue dipendenze e le raggruppa fino alla fine della catena.
Se c'è un file che non sa come caricare in quella catena di dipendenze, verrà generato questo tipo di errore.
Questo a volte può essere risolto aggiungendo un caricatore che sappia come caricare questo tipo di dipendenza. Se, tuttavia, la dipendenza è un modulo non nativo, Webpack non può caricarlo. Alcuni dei caricatori sanno come caricare moduli con dipendenze non native eliminando ed escludendo la parte non nativa in modo che venga caricata. Nel fs modulo, ad esempio, non è necessario essere in grado di leggere e scrivere file dal disco perché il browser non può farlo, quindi non è necessario includere quella parte.
Ciò solleva la domanda:quale funzionalità del modulo mangusta hai bisogno nel browser? Puoi includere solo quella funzionalità e non l'intero modulo mangusta?
Se sei in grado di farlo, potresti essere in grado di risolvere 2 problemi:
- Potresti risolvere il problema del raggruppamento di Webpack perché la parte di mangusta che stai includendo nel tuo progetto non ha dipendenze secondarie problematiche.
- Creerai un pacchetto più piccolo con Webpack perché includerai solo le parti di cui hai bisogno, quindi il carico utile bundle.js per il client sarà molto più piccolo.
Ad esempio, di recente ho dovuto utilizzare il generatore di ObjectId mongodb nel client. Ho scoperto che Webpack non era in grado di gestire l'import mongodb from 'mongodb' componente così scavando nelle dipendenze ho trovato che mongodb dipende da mongodb-core che dipende da bson che ha il ObjectId metodo di cui avevo bisogno.
Importando solo il bson componente di quella catena di dipendenze ho aggirato il problema di Webpack e ho reso il mio bundle molto più piccolo.
Se stai usando Npm 3, ci sono buone probabilità che bson è installato nella radice di node_modules se stai già utilizzando mongoose o mongodb, puoi import senza inserire un riferimento esplicito ad esso nel tuo package.json . Questo ovviamente comporta il rischio che se la dipendenza superiore si interrompe a seconda di essa, la tua build si rompe e dovrai npm install esso in modo indipendente. Il vantaggio di utilizzare questo approccio è che utilizzerai sempre la stessa versione di bson che la dipendenza superiore sta usando, il che potrebbe essere importante.
