Deze documentatie beantwoordt mijn vraag zeer slecht. Ik heb die uitleg niet begrepen. Kan iemand het in eenvoudiger woorden zeggen? Misschien met voorbeelden als het's moeilijk is om eenvoudige woorden te kiezen?
EDIT ook peerDependencies
toegevoegd, wat nauw verwant is en verwarring kan veroorzaken.
Samenvatting van belangrijke gedragsverschillen:
dependencies
]1 worden op beide geïnstalleerd:npm install
vanuit een map die package.json
bevatnpm install $package
op elke andere directorydevDependencies
]2 zijn:npm install
op een directory die package.json
bevat, tenzij je de --production
vlag doorgeeft (ga upvote Gayan Charith's antwoord).npm install "$package"
op een andere directory, tenzij u het de --dev
optie geeft.peerDependencies
:npm install
, en je moet de afhankelijkheid zelf handmatig oplossen. Bij het draaien, als de dependency ontbreekt, krijg je een foutmelding (genoemd door @nextgentech)dependencies
worden transitief geïnstalleerd: als A B vereist, en B vereist C, dan wordt C geïnstalleerd, anders zou B niet kunnen werken, en A ook niet.devDependencies
wordt niet transitief geïnstalleerd. Bv. we hoeven B niet te testen om A te testen, dus B's testing dependencies kunnen weggelaten worden.
Verwante opties die hier niet besproken worden:bundledDependencies
die besproken wordt op de volgende vraag: https://stackoverflow.com/questions/11207638/advantages-of-bundleddependencies-over-normal-dependencies-in-npm?lq=1optionalDependencies
]8 (genoemd door Aidan Feldman)dependencies
zijn nodig om te draaien, devDependencies
alleen om te ontwikkelen, bv: unit tests, CoffeeScript naar JavaScript transpilatie, minificatie, ...
Als je een package gaat ontwikkelen, download je het (bv. via git clone
), ga je naar de root die package.json
bevat, en voer je uit:
npm install
Aangezien je de broncode hebt, is het duidelijk dat je het wilt ontwikkelen, dus worden standaard zowel dependencies
(aangezien je natuurlijk moet draaien om te ontwikkelen) als devDependency
afhankelijkheden ook geïnstalleerd.
Als je echter alleen maar een eindgebruiker bent die een pakket wil installeren om het te gebruiken, dan doe je dat vanuit elke directory:
npm install "$package"
In dat geval wil je normaal gesproken niet de ontwikkelings-afhankelijkheden, dus krijg je alleen wat nodig is om het pakket te gebruiken: dependencies
.
Wil je in dat geval echt ontwikkelpakketten installeren, dan kun je de dev
configuratie-optie op true
zetten, eventueel vanaf de commandoregel als:
npm install "$package" --dev
De optie staat standaard op false
omdat dit een veel minder voorkomend geval is.
(Getest voor 3.0)
Bron: https://nodejs.org/en/blog/npm/peer-dependencies/
Met gewone dependencies kun je meerdere versies van de dependency hebben: het'wordt gewoon geïnstalleerd in de node_modules
van de dependency.
Bijvoorbeeld, als dependency1
en dependency2
beide afhankelijk zijn van dependency3
in verschillende versies, dan ziet de projectboom er als volgt uit:
root/node_modules/
|
+- dependency1/node_modules/
| |
| +- dependency3 v1.0/
|
|
+- dependency2/node_modules/
|
+- dependency3 v2.0/
Plugins zijn echter pakketten die normaal gesproken het andere pakket niet nodig hebben, dat in deze context de host wordt genoemd. In plaats daarvan:
dependency1
en dependency2
peer afhankelijk zijn van dependency3
, dan zal de projectboom er als volgt uitzien:root/node_modules/
|
+- dependency1/
|
+- dependency2/
|
+- dependency3 v1.0/
Dit gebeurt zelfs als je dependency3
nooit noemt in je package.json
bestand.
Ik denk dat dit een voorbeeld is van het Inversion of Control ontwerp patroon.
Een prototypisch voorbeeld van peer dependencies is Grunt, de host, en zijn plugins.
Bijvoorbeeld, op een Grunt plugin zoals https://github.com/gruntjs/grunt-contrib-uglify, zul je zien dat:
grunt
is een peer-dependency
require('grunt')
is onder tests/
: het'wordt niet echt gebruikt door het programma.
Dan, wanneer de gebruiker een plugin zal gebruiken, zal hij impliciet de plugin uit de Gruntfile
vereisen door een grunt.loadNpmTasks('grunt-contrib-uglify')
regel toe te voegen, maar het's grunt
dat de gebruiker direct zal aanroepen.
Dit zou dan niet werken als elke plugin een andere Grunt versie vereist.Ik denk dat de documentatie de vraag vrij goed beantwoordt, misschien ben je net niet vertrouwd genoeg met node / andere pakketbeheerders. Ik begrijp het waarschijnlijk alleen omdat ik een beetje weet over Ruby bundler. De belangrijkste regel is:
Deze dingen zullen worden geïnstalleerd bij het doen van npm link of npm install vanuit de root van een pakket en kunnen worden beheerd als elke andere npm-configuratieparameter. Zie npm-config(7) voor meer over het onderwerp. En dan onder npm-config(7) zoek
dev
:
Default: false
Type: Boolean
Install dev-dependencies along with packages.
Er zijn sommige modules en pakketten alleen nodig voor ontwikkeling, die niet nodig zijn in productie. Zoals het in de documentatie staat:
Als iemand van plan is om uw module te downloaden en te gebruiken in hun programma, dan willen of hoeven ze waarschijnlijk niet het externe test- of documentatieraamwerk dat u gebruikt te downloaden en te bouwen. In dit geval is het's best om deze extra items in een devDependencies hash te vermelden.