node.js download - Quelle est la différence entre dépendances, devDependencies et peerDependencies dans le fichier npm package.json?




install ubuntu (8)

Une explication simple qui me l'a fait comprendre est:

Lorsque vous déployez votre application, les modules dans les dépendances doivent être installés ou votre application ne fonctionnera pas. Les modules de devDependencies n'ont pas besoin d'être installés sur le serveur de production car vous ne développez pas sur cette machine. link

Cette documentation répond très mal à ma question. Je n'ai pas compris ces explications. Quelqu'un peut-il dire en termes plus simples? Peut-être avec des exemples s'il est difficile de choisir des mots simples?


Je voudrais ajouter à la réponse mon point de vue sur ces explications de dépendances

  • dependencies sont utilisées pour une utilisation directe dans votre base de code, les choses qui finissent généralement dans le code de production, ou des morceaux de code
  • devDependencies sont utilisées pour le processus de construction, des outils qui vous aident à gérer la fin du code de fin, des modules de test tiers (par exemple, des paquets webpack)

Pour enregistrer un package dans package.json en tant que dépendance dev:

npm install "$package" --save-dev

Lorsque vous exécutez npm install il installe à la fois devDependencies et dependencies . Pour éviter l'installation, devDependencies s'exécute:

npm install --production

A titre d'exemple, moka serait normalement une dépendance de type Dev, car le test n'est pas nécessaire en production, alors que Express serait une dépendance.


Certains modules et paquets sont uniquement nécessaires au développement, qui ne sont pas nécessaires en production. Comme il le dit dans la documentation :

Si quelqu'un envisage de télécharger et d'utiliser votre module dans son programme, alors il ne veut probablement pas ou ne doit pas télécharger et construire le test externe ou le cadre de documentation que vous utilisez. Dans ce cas, il est préférable de lister ces éléments supplémentaires dans un hachage devDependencies.


Si vous ne voulez pas installer devDependencies, vous pouvez simplement utiliser npm install --production


Résumé des différences de comportement importantes:

  • dependencies sont installées sur les deux:

    • npm install de npm install partir d'un répertoire contenant package.json
    • npm install $package sur tout autre répertoire
  • devDependencies sont:

    • également installé sur npm install sur un répertoire qui contient package.json , sauf si vous passez le drapeau --production (allez upvote réponse de Gayan Charith ).
    • non installé sur npm install "$package" sur tout autre répertoire, sauf si vous lui donnez l'option --dev .
    • ne sont pas installés de manière transitive.
  • peerDependencies :

    • avant la version 3.0: sont toujours installés s'ils sont manquants et déclenchent une erreur si plusieurs versions incompatibles de la dépendance sont utilisées par des dépendances différentes.
    • attendu à partir de la 3.0 (non testé): donner un avertissement s'il manque sur l' npm install , et vous devez résoudre manuellement la dépendance. Lors de l'exécution, si la dépendance est manquante, vous obtenez une erreur (mentionnée par @nextgentech )
  • Transitivité (mentionné par Ben Hutchison ):

    • dependencies sont installées de manière transitive: si A requiert B, et B requiert C, alors C est installé, sinon B ne pourrait pas fonctionner, et A.

    • devDependencies ne sont pas installées de manière transitive. Par exemple, nous n'avons pas besoin de tester B pour tester A, donc les dépendances de test de B peuvent être omises.

Options connexes non abordées ici:

devDependencies

dependencies sont nécessaires à l'exécution, devDependencies uniquement pour développer, par exemple: tests unitaires, Coffeescript à Javascript transpilation, minification, ...

Si vous allez développer un paquet, vous le téléchargez (par exemple via git clone ), allez à sa racine qui contient package.json , et lancez:

npm install

Puisque vous avez la source réelle, il est clair que vous voulez la développer, donc par défaut les deux dependencies (puisque vous devez bien sûr courir pour développer) et les dépendances de devDependency sont également installées.

Si toutefois vous n'êtes qu'un utilisateur final qui veut juste installer un paquet pour l'utiliser, vous le ferez depuis n'importe quel répertoire:

npm install "$package"

Dans ce cas, vous ne voulez normalement pas les dépendances de développement, donc vous obtenez juste ce qui est nécessaire pour utiliser le paquet: dependencies .

Si vous souhaitez vraiment installer des packages de développement dans ce cas, vous pouvez définir l'option dev config sur true , éventuellement à partir de la ligne de commande comme:

npm install "$package" --dev

L'option est false par défaut car c'est un cas beaucoup moins commun.

peerDependencies

(testé avant 3.0)

Source: https://nodejs.org/en/blog/npm/peer-dependencies/

Avec les dépendances régulières, vous pouvez avoir plusieurs versions de la dépendance: elle est simplement installée dans les node_modules de la dépendance.

Par exemple, si dependency1 et dependency2 dépendent toutes dependency2 deux de dependency3 à des versions différentes, l'arborescence du projet ressemblera à ceci:

root/node_modules/
                 |
                 +- dependency1/node_modules/
                 |                          |
                 |                          +- dependency3 v1.0/
                 |
                 |
                 +- dependency2/node_modules/
                                            |
                                            +- dependency3 v2.0/

Les plugins sont cependant des paquets qui normalement n'ont pas besoin de l'autre paquet, qui est appelé l' hôte dans ce contexte. Au lieu:

  • les plugins sont requis par l'hôte
  • les plugins offrent une interface standard que l'hôte s'attend à trouver
  • Seul l'hôte sera appelé directement par l'utilisateur, il doit donc y en avoir une seule version.

Par exemple, si dependency1 et dependency2 peer dépendent de dependency3 , l'arborescence du projet ressemblera à ceci:

root/node_modules/
                 |
                 +- dependency1/
                 |
                 +- dependency2/
                 |
                 +- dependency3 v1.0/

Cela arrive même si vous ne mentionnez jamais dependency3 dans votre fichier package.json .

Je pense que c'est une instance du modèle de conception Inversion of Control .

Un exemple prototypique de dépendances entre homologues est Grunt, l'hôte et ses plugins.

Par exemple, sur un plugin Grunt comme https://github.com/gruntjs/grunt-contrib-uglify , vous verrez que:

  • grunt est un peerDependency
  • le seul require('grunt') est sous tests/ : il n'est pas réellement utilisé par le programme.

Ensuite, quand l'utilisateur utilisera un plugin, il impliquera implicitement le plugin du Gruntfile en ajoutant une ligne grunt.loadNpmTasks('grunt-contrib-uglify') , mais il est grunt que l'utilisateur appelle directement.

Cela ne fonctionnerait pas si chaque plugin nécessitait une version différente de Grunt.

Manuel

Je pense que le doc répond assez bien à la question, peut-être que vous n'êtes pas assez familier avec les gestionnaires de paquets / nœuds. Je ne le comprends probablement que parce que je connais un peu le bundler Ruby.

La ligne clé est:

Ces éléments seront installés lors de l'installation de npm link ou npm à partir de la racine d'un paquet, et peuvent être gérés comme n'importe quel autre paramètre de configuration npm. Voir npm-config (7) pour plus d'informations sur le sujet.

Et puis sous npm-config (7) trouvez dev :

Default: false
Type: Boolean

Install dev-dependencies along with packages.

Vous pouvez trouver une comparaison technique sur npmcompare

Comparaison de browserify et de grunt vs. gulp vs. webpack

Comme vous pouvez le voir, webpack est très bien entretenu avec une nouvelle version qui sort tous les 4 jours en moyenne. Mais Gulp semble avoir la plus grande communauté de tous (avec plus de 20K étoiles sur Github) Grunt semble un peu négligé (par rapport aux autres)

Donc, si besoin de choisir l'un sur l'autre je voudrais aller avec Gulp





node.js npm