I vantaggi di bundledDependencies rispetto alle normali dipendenze in NPM

Question

npm ci consente di specificare bundledDependencies ma quali sono i vantaggi di farlo? Immagino che se vogliamo essere assolutamente sicuri di ottenere la versione giusta anche se il modulo che facciamo riferimento viene eliminato, o forse c'è un vantaggio di velocità con il raggruppamento?

Qualcuno conosce i vantaggi di bundledDependencies rispetto alle normali dipendenze?

estratto di definizione bundledDependencies qui per comodità:

bundledDependencies
array di nomi di pacchetti che saranno in bundle durante la pubblicazione del pacchetto.

Se questo è scritto "bundleDependencies", allora questo è anche onorevole.

E.g. bundledDependencies: ['foo', 'bar']

Answer 1

Uno dei maggiori problemi in questo momento con Nodo è la velocità con cui sta cambiando. Ciò significa che i sistemi di produzione possono essere molto fragili e un npm update può facilmente rompere le cose.

L'utilizzo di bundledDependencies è un modo per aggirare questo problema, assicurando, come si è giustamente ipotizzato, che fornirai sempre le dipendenze corrette indipendentemente da che cosa potrebbe cambiare.

Puoi anche utilizzarlo per raggruppare i tuoi bundle privati ​​e consegnarli con l'installazione.

Answer 2

Un altro vantaggio è che è possibile inserire le proprie dipendenze interne (componenti dell'applicazione) e quindi richiederle nella propria app come se fossero moduli indipendenti anziché ingombrare la lib/e pubblicarle su npm.

Se/quando sono maturati al punto che potrebbero vivere come moduli separati, è possibile metterli su npm facilmente, senza modificare il codice.

Answer 3

Per il rapido lettore di: questo QA è di circa il campo package.json bundledDependencies, non sulla package.

Cosa bundledDependencies fanno

"bundledDependencies" sono esattamente ciò che implica il loro nome. Dipendenze che dovrebbero essere all'interno del tuo progetto. Quindi la funzionalità è fondamentalmente la stessa delle normali dipendenze. Saranno anche imballati durante l'esecuzione di npm pack.

Quando usarli

dipendenze normali sono in genere installati dal Registro di NPM. dipendenze Così in bundle sono utili quando:

• si desidera riutilizzare una libreria di terze parti che non proviene dal Registro di NPM, o che è stato modificato
• volete riutilizzare i propri progetti come i moduli
• si desidera distribuire alcuni file con il modulo

In questo modo, non c'è bisogno di creare (e mantenere) il proprio repository NPM, ma ottenere gli stessi benefici che si ottiene da pacchetti NPM.

Quando non di utilizzare le dipendenze

Quando si sviluppa in bundle, non credo che il punto principale è quello di evitare che gli aggiornamenti accidentali però. Abbiamo strumenti migliori per questo, vale a dire repository di codici (git, mercurial, svn ...) o ora lock file.

Per aggiungere i tuoi versioni del pacchetto, è possibile utilizzare:

• Option1: Utilizzare la più recente NPM versione 5 che viene fornito con il nodo 8. Si utilizza un file package-lock.json (vedi la node blog e il rilascio del nodo 8)

• Opzione2: utilizzare yarn anziché npm. È un gestore di pacchetti da facebook, più veloce di npm e utilizza un file yarn.lock. Utilizza lo stesso package.json in caso contrario.

Ciò è paragonabile file di lock in altri gestori di pacchetti come Bundler o Cargo. È simile al npm-shrinkwrap.json di npm, tuttavia non è lossy e crea risultati riproducibili.

npm ha effettivamente copiato questa funzione da yarn, tra le altre cose.

• Opzione3: questo era l'approccio consigliato in precedenza, che non consiglio più. L'idea era di usare la npm shrinkwrap la maggior parte del tempo, e qualche volta mettere l'intera cosa, inclusa la cartella node_module, nel tuo repository di codice. O possibilmente usare shrinkpack. Le migliori pratiche al momento sono state discusse su node.js blog e sui siti Web joyent developer.

Vedi anche

Questo è un po 'al di fuori della portata della questione, ma mi piacerebbe citare l'ultimo tipo di dipendenze (che io sappia): peer dependencies. Vedi anche questo related SO question ed eventualmente i documenti di yarn su bundledDependencies.

Answer 4

Operativamente, guardo bundledDependencies come archivio di moduli privati ​​di un modulo, in cui le dipendenze sono più pubbliche, risolte tra il modulo e le sue dipendenze (e dipendenze secondarie). Il tuo modulo può fare affidamento su una versione precedente, diciamo, di reazione, ma una dipendenza richiede l'ultima e la più grande.Il tuo pacchetto/installazione comporterà la tua versione bloccata in node_modules/$yourmodule/node_modules/react, mentre la tua dipendenza otterrà la loro versione in node_modules/react (o node_modules/$dependency/node_modules/react se sono così inclini).

Un avvertimento: recentemente mi sono imbattuto in una dipendenza che non configurava correttamente la sua dipendenza dalla reazione, e avendo reagito in bundledDependencies ha causato il guasto del modulo dipendente al runtime.