Perché, ad esempio, un plug-in Grunt definisce la sua dipendenza da grunt come " dipendenze tra pari "?

Perché il plugin non può avere Grunt come propria dipendenza in grunt-plug / node_modules ?

Le dipendenze tra pari sono descritte qui: https://nodejs.org/en/blog/npm/peer-dependencies/

Ma non capisco davvero.

Esempio

Al momento sto lavorando con AppGyver Steroids, che utilizza le attività di Grunt per creare i miei file sorgente in una cartella / dist / da servire su un dispositivo locale. Sono abbastanza nuovo su npm e grugnito, quindi voglio comprendere appieno cosa sta succedendo.

Finora ho capito questo:

[rootfolder] /package.json dice a npm che dipende dal grunt-steroidspacchetto npm per lo sviluppo:

  "devDependencies": {
    "grunt-steroids": "0.x"
  },

Va bene. L'esecuzione di npm install in [rootfolder] rileva la dipendenza e installa grunt-steroidi in [rootfolder] / node_modules / grunt-steroids .

Npm quindi legge [rootfolder] /node_modules/grunt-steroids/package.json in modo da poter installare le grunt-steroidsproprie dipendenze .:

"devDependencies": {
    "grunt-contrib-nodeunit": "0.3.0",
    "grunt": "0.4.4"
  },
"dependencies": {
    "wrench": "1.5.4",
    "chalk": "0.3.0",
    "xml2js": "0.4.1",
    "lodash": "2.4.1"
  },
"peerDependencies": {
    "grunt": "0.4.4",
    "grunt-contrib-copy": "0.5.0",
    "grunt-contrib-clean": "0.5.0",
    "grunt-contrib-concat": "0.4.0",
    "grunt-contrib-coffee": "0.10.1",
    "grunt-contrib-sass": "0.7.3",
    "grunt-extend-config": "0.9.2"
  },

I pacchetti " dipendenze " sono installati in [rootfolder] / node_modules / grunt-steroids / node_modules che è logico per me.

Le " devDependencies " non sono installate, che sono sicuro che è controllato da npm rilevando che sto solo cercando di usare grunt-steroidse non svilupparle.

Ma poi abbiamo le " Dipendenze tra pari ".

Questi sono installati in [rootfolder] / node_modules e non capisco perché lì e non in [rootfolder] / node_modules / grunt-steroids / node_modules in modo da evitare conflitti con altri plug -in grugniti (o altro)?

TL; DR: peerDependencies sono per le dipendenze che sono esposte (e si prevede che saranno utilizzate da) il codice di consumo, al contrario delle dipendenze "private" che non sono esposte e sono solo un dettaglio di implementazione.

Il problema delle dipendenze tra pari si risolve

Il sistema di moduli di NPM è gerarchico. Un grande vantaggio per gli scenari più semplici è che quando si installa un pacchetto npm, quel pacchetto porta le proprie dipendenze con esso in modo che funzioni immediatamente.

Ma sorgono problemi quando:

• Sia il tuo progetto che alcuni moduli che stai utilizzando dipendono da un altro modulo.
• I tre moduli devono dialogare.

Per esempio

Diciamo che stai costruendo YourCoolProjecte stai usando entrambi JacksModule 1.0e JillsModule 2.0. E supponiamo che JacksModuledipenda anche da JillsModule, ma da una versione diversa, diciamo 1.0. Finché quelle 2 versioni non si incontrano, non ci sono problemi. Il fatto che JacksModulesta usando JillsModulesotto la superficie è solo un dettaglio di implementazione. Stiamo raggruppando JillsModuledue volte, ma questo è un piccolo prezzo da pagare quando otteniamo un software stabile pronto all'uso.

Ma ora se JacksModuleesponesse la sua dipendenza JillsModulein qualche modo. Ad esempio accetta un'istanza di JillsClass... Cosa succede quando creiamo una new JillsClassversione 2.0della libreria e la passiamo a jacksFunction? Si scatenerà l'inferno! Cose semplici come jillsObject instanceof JillsClassimprovvisamente torneranno falseperché in jillsObjectrealtà è un'istanza di un'altra JillsClass , la 2.0versione.

Come le dipendenze dei pari risolvono questo problema

Dicono a npm

Ho bisogno di questo pacchetto, ma ho bisogno della versione che fa parte del progetto, non di una versione privata del mio modulo.

Quando npm vede che il tuo pacchetto viene installato in un progetto che non ha quella dipendenza, o che ne ha una versione incompatibile , avviserà l'utente durante il processo di installazione.

Quando dovresti usare le dipendenze tra pari?

• Quando stai costruendo una libreria per essere utilizzata da altri progetti, e
• Questa libreria sta utilizzando un'altra libreria e
• Ti aspetti / hai bisogno che l'utente lavori anche con quell'altra libreria

Gli scenari comuni sono plugin per framework più grandi. Pensa a cose come Gulp, Grunt, Babel, Mocha, ecc. Se scrivi un plug-in Gulp, vuoi che quel plug-in funzioni con lo stesso Gulp utilizzato dal progetto dell'utente, non con la tua versione privata di Gulp.

Ti consiglierei di leggere di nuovo l'articolo prima. È un po 'confuso ma l'esempio con winston-mail ti mostra la risposta perché:

Ad esempio, facciamo finta che sia winston-mail@0.2.3specificato "winston": "0.5.x"nel suo "dependencies"oggetto perché è l'ultima versione per cui è stato testato. Come sviluppatore di app, vuoi le cose più recenti e migliori, quindi cerchi le ultime versioni di winstone di winston-maile inseriscile nel tuo pacchetto. Json as

{
  "dependencies": {  
    "winston": "0.6.2",  
    "winston-mail": "0.2.3"  
  }  
}

Ma ora, l'esecuzione di npm install risulta nel grafico delle dipendenze impreviste di

├── winston@0.6.2  
└─┬ winston-mail@0.2.3                
  └── winston@0.5.11

In questo caso, è possibile avere più versioni di un pacchetto che potrebbero causare alcuni problemi. Le dipendenze tra pari consentono agli sviluppatori npm di assicurarsi che l'utente disponga del modulo specifico (nella cartella principale). Ma hai ragione sul fatto che la descrizione di una versione specifica di un pacchetto porterebbe a problemi con altri pacchetti che usano altre versioni. Questo problema ha a che fare con gli sviluppatori npm, come afferma l'articolo

Un consiglio : i requisiti di dipendenza tra pari, a differenza di quelli per le dipendenze regolari, dovrebbero essere indulgenti . Non è necessario bloccare le dipendenze dei peer fino a versioni di patch specifiche.

Pertanto gli sviluppatori dovrebbero seguire semver per la definizione di peerDependencies. Si dovrebbe aprire un problema per il pacchetto di steroidi grunt su GitHub ...

peerDependencies spiegato con l'esempio più semplice possibile:

{
  "name": "myPackage",
  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }
}


{
  "name": "foo"
  "peerDependencies": {
    "react": "^16.0.0"
  }
}

l'esecuzione di npm install in myPackage genererà un errore perché sta tentando di installare la versione di React ^15.0.0E fooche è compatibile solo con React ^16.0.0.

le peerDependencies NON sono installate.