2 manuels sur gulp indiquent que je dois d'abord installer gulp globalement (avec -g flag), puis une fois de plus localement. Pourquoi ai-je besoin de ça?
Lors de l'installation globale d'un outil, il doit être utilisé par un utilisateur en tant qu'utilitaire de ligne de commande, où qu'il soit, y compris en dehors des projets de nœud. Les installations globales d'un projet de noeud sont mauvaises car elles rendent le déploiement plus difficile.
L'utilitaire npx
fourni avec npm
5.2
résout ce problème. Grâce à cela, vous pouvez appeler des utilitaires installés localement, tels que des utilitaires installés globalement (mais vous devez commencer la commande avec npx
). Par exemple, si vous souhaitez appeler un eslint
installé localement, vous pouvez effectuer les opérations suivantes:
npx eslint .
Lorsqu'il est utilisé dans un champ script
de votre package.json, npm
recherche node_modules
pour l'outil ainsi que pour les modules installés globalement, de sorte que l'installation locale est suffisante.
Donc, si vous êtes satisfait de (dans votre package.json):
"devDependencies": {
"gulp": "3.5.2"
}
"scripts": {
"test": "gulp test"
}
etc. et en cours d'exécution avec npm run test
, vous ne devriez pas du tout avoir besoin de l'installation globale.
Les deux méthodes sont utiles pour configurer les personnes avec votre projet, car Sudo
n'est pas nécessaire. Cela signifie également que gulp
sera mis à jour lorsque la version sera modifiée dans package.json, de sorte que tout le monde utilisera la même version de gulp lors du développement avec votre projet.
Il semble que gulp ait un comportement inhabituel lorsqu'il est utilisé à l'échelle mondiale. Lorsqu'il est utilisé en tant qu'installation globale, gulp recherche un gulp installé localement auquel contrôler. Par conséquent, une installation globale gulp nécessite une installation locale gulp pour fonctionner. La réponse ci-dessus est toujours valable. Les installations locales sont toujours préférables aux installations globales.
TLDR; Voici pourquoi :
Cela fonctionne parce que
gulp
essaie d'exécuter votregulpfile.js
en utilisant votre version degulp
installée localement, voir ici . D'où la raison d'une installation globale et locale de gulp.
En règle générale, lorsque vous installez gulp
localement, le script ne figure pas dans votre PATH
et vous ne pouvez donc pas simplement taper gulp
et attendre que le shell trouve la commande. En l'installant globalement, le script gulp
entre dans votre répertoire PATH
car le répertoire global node/bin/
se trouve probablement sur votre chemin.
Cependant, pour respecter vos dépendances locales, gulp
utilisera votre version de celle-ci installée localement pour exécuter le gulpfile.js
.
Vous pouvez lier localement gulp
installé globalement avec
npm link gulp
La question " Pourquoi devons-nous installer gulp globalement et localement? " peut être décomposée en deux questions suivantes:
Pourquoi dois-je installer gulp localement si je l'ai déjà installé globalement?
Pourquoi dois-je installer gulp globalement si je l'ai déjà installé localement?
Plusieurs autres ont fourni d’excellentes réponses à ces questions isolément, mais j’ai pensé qu’il serait utile de regrouper les informations dans une réponse unifiée.
Pourquoi ai-je besoin d'installer gulp localement si je l'ai déjà installé globalement?
La raison pour installer gulp localement est composée de plusieurs raisons:
Pourquoi ai-je besoin d'installer gulp globalement si je l'ai déjà installé localement?
Pour éviter d'installer localement, vous pouvez utiliser npm link [package]
, mais la commande link ainsi que la commande install --global
ne semblent pas prendre en charge l'option --save-dev
, ce qui signifie qu'il ne semble pas qu'il moyen facile d’installer gulp globalement, puis d’ajouter facilement la version à votre fichier package.json local.
En fin de compte, j'estime qu'il est plus logique de pouvoir utiliser des modules globaux pour éviter de dupliquer l'installation d'outils communs à tous vos projets, en particulier dans le cas d'outils de développement tels que Grunt, Gulp, Jshint, etc. Malheureusement, il Il semble que vous finissez par vous battre un peu contre les outils quand vous allez à contre-courant.
Techniquement, vous n'avez pas besoin de l'installer globalement si le dossier node_modules
de votre installation locale se trouve dans votre PATH
. Généralement ce n'est pas une bonne idée.
Alternativement, si npm test
fait référence à gulp
, vous pouvez simplement taper npm test
et exécuter l'exécution de la gulp locale.
Je n'ai jamais installé gulp globalement - je pense que c'est une mauvaise forme.
Je ne sais pas si notre problème était directement lié à l'installation de gulp uniquement localement. Mais nous avons dû installer nous-mêmes un tas de dépendances. Cela a conduit à un "énorme" package.json et nous ne savons pas si c'est vraiment une bonne idée d'installer gulp uniquement localement. Nous devions le faire à cause de notre environnement de construction. Mais je ne recommanderais pas d'installer gulp pas globalement si ce n'est pas absolument nécessaire. Nous avons rencontré des problèmes similaires à ceux décrits ci-dessous blog-post
Aucun de ces problèmes ne se pose à aucun de nos développeurs sur leurs machines locales car ils ont tous installé gulp globalement. Sur le système de construction, nous avons eu les problèmes décrits. Si quelqu'un est intéressé, je pourrais approfondir cette question. Mais pour l’instant, je voulais seulement mentionner qu’il n’est pas facile d’installer gulp uniquement localement.
Juste parce que je ne l’ai pas vu ici, si vous êtes sur MacOS ou Linux, je vous suggère d’ajouter ceci à votre PATH (dans votre répertoire de base, etc.):
node_modules/.bin
Avec cette entrée de chemin relatif, si vous êtes assis dans le dossier racine d’un projet de noeud, vous pouvez exécuter n’importe quel outil de ligne de commande (eslint, gulp, etc.) sans vous soucier des "installations globales" ou de npm run
etc. .
Une fois que j'ai fait cela, je n'ai jamais installé de module globalement.