Riepilogo di importanti differenze comportamentali:
Opzioni correlate non discusse qui:
devDependencies
dependenciessono necessari per l'esecuzione, devDependenciessolo per lo sviluppo, ad esempio: unit test, conversione da CoffeeScript a JavaScript, minificazione, ...
Se hai intenzione di sviluppare un pacchetto, lo scarichi (ad es. Via git clone), vai alla sua radice che contiene package.jsoned esegui:
npm install
Dal momento che hai la fonte reale, è chiaro che vuoi svilupparla, quindi per impostazione predefinita, sono installati sia dependencies(poiché, ovviamente, devi correre per sviluppare) sia le devDependencydipendenze.
Se tuttavia, sei solo un utente finale che desidera semplicemente installare un pacchetto per usarlo, lo farai da qualsiasi directory:
npm install "$package"
In questo caso, normalmente non si desidera che le dipendenze di sviluppo, quindi basta avere ciò che è necessario per utilizzare il pacchetto: dependencies.
Se vuoi davvero installare i pacchetti di sviluppo in quel caso, puoi impostare l' devopzione di configurazione su true, possibilmente dalla riga di comando come:
npm install "$package" --dev
L'opzione è falsedi default poiché questo è un caso molto meno comune.
peerDependencies
(Testato prima di 3.0)
Fonte: https://nodejs.org/en/blog/npm/peer-dependencies/
Con le dipendenze regolari, è possibile avere più versioni della dipendenza: è semplicemente installata all'interno node_modulesdella dipendenza.
Ad esempio, se dependency1e dependency2entrambi dipendono dependency3in diverse versioni ad albero del progetto sarà simile:
root/node_modules/
|
+- dependency1/node_modules/
| |
| +- dependency3 v1.0/
|
|
+- dependency2/node_modules/
|
+- dependency3 v2.0/
I plug-in, tuttavia, sono pacchetti che normalmente non richiedono l'altro pacchetto, chiamato host in questo contesto. Anziché:
- i plugin sono richiesti dall'host
- i plugin offrono un'interfaccia standard che l'host si aspetta di trovare
- solo l'host verrà chiamato direttamente dall'utente, quindi deve esserci una sola versione di esso.
Ad esempio, se dependency1e dependency2peer dipendono dependency3, l'albero del progetto sarà simile a:
root/node_modules/
|
+- dependency1/
|
+- dependency2/
|
+- dependency3 v1.0/
Questo succede anche se non hai mai menzionato dependency3nel tuo package.jsonfile.
Penso che questa sia un'istanza del modello di progettazione di Inversion of Control .
Un esempio prototipico di dipendenze tra pari è Grunt, l'host e i suoi plugin.
Ad esempio, su un plug-in Grunt come https://github.com/gruntjs/grunt-contrib-uglify , vedrai che:
grunt è un peer-dependency- l'unico
require('grunt')è sotto tests/: non è effettivamente utilizzato dal programma.
Quindi, quando l'utente utilizzerà un plugin, richiederà implicitamente il plugin Gruntfileaggiungendo una grunt.loadNpmTasks('grunt-contrib-uglify')linea, ma è gruntche l'utente chiamerà direttamente.
Questo non funzionerebbe quindi se ogni plugin richiedesse una versione di Grunt diversa.
Manuale
Penso che la documentazione risponda abbastanza bene alla domanda, forse non hai abbastanza familiarità con i gestori di nodi / altri pacchetti. Probabilmente lo capisco solo perché conosco un po 'il bundler di Ruby.
La linea chiave è:
Queste cose verranno installate quando si esegue npm link o npm install dalla radice di un pacchetto e possono essere gestite come qualsiasi altro parametro di configurazione npm. Vedi npm-config (7) per ulteriori informazioni sull'argomento.
E poi sotto npm-config (7) trova dev:
Default: false
Type: Boolean
Install dev-dependencies along with packages.
optionalDependenciesora.