En utilisant npm, nous pouvons installer les modules globalement en utilisant l' -g
option. Comment pouvons-nous faire cela dans le fichier package.json?
Supposons que ce soient mes dépendances dans le fichier package.json
"dependencies": {
"mongoose": "1.4.0",
"node.io" : "0.3.3",
"jquery" : "1.5.1",
"jsdom" : "0.2.0",
"cron" : "0.1.2"
}
Quand je cours npm install
, je veux seulement node.io
être installé globalement, les autres doivent être installés localement. Y a-t-il une option pour cela?
"preferGlobal": true
intérieur de package.json pour un module."preferGlobal":true
... je ne sais pas vraiment où mettre cela dans package.json. npmjs.org/doc/json.html La documentation NPM indique que preferGlobal est pour votre propre paquet et que ce paramètre le fera installer votre propre paquet en tant que global. cela ressemble plus à un guide, cependant.Réponses:
Nouvelle note: vous ne voulez probablement pas ou n'avez pas besoin de faire cela. Ce que vous voulez probablement faire, c'est simplement mettre ces types de dépendances de commandes pour build / test, etc. dans la
devDependencies
section de votre package.json. Chaque fois que vous utilisez quelque chose descripts
package.json, vos commandes devDependencies (dans node_modules / .bin) agissent comme si elles se trouvaient dans votre chemin.Par exemple:
Puis dans package.json:
Ensuite, à votre invite de commande, vous pouvez exécuter:
Mais si vous voulez vraiment installer globalement, vous pouvez ajouter une pré-installation dans la section scripts du package.json:
Donc en fait mon installation npm exécute à nouveau l'installation de npm .. ce qui est bizarre mais semble fonctionner.
Remarque: vous pouvez rencontrer des problèmes si vous utilisez la configuration la plus courante pour les
npm
emplacements d'installation du package global Nodesudo
. Une option consiste à modifier votrenpm
configuration, ce n'est donc pas nécessaire:npm config set prefix ~/npm
, ajoutez $ HOME / npm / bin à $ PATH en ajoutantexport PATH=$HOME/npm/bin:$PATH
à votre fichier~/.bashrc
.la source
npm i -g underscore-cli
. cela donne un avertissement sur le fait que wd se trompe. wd signifie répertoire de travail, je suppose. lorsque je fais cela manuellement sur la ligne de commande, les choses se passent bien, mais je préférerais que l'utilisateur puisse gérer l'installation de mon code avec un simplenpm install
npm list module -g || npm install module -g
as npm renverra les valeurs de sortie appropriées."preinstall" : "scripts/preinstall.sh"
).&&
, par exemplenpm install -g bower && npm install -g grunt-cli
En raison des inconvénients décrits ci-dessous, je recommanderais de suivre la réponse acceptée:
Ma réponse originale mais non recommandée suit.
Au lieu d'utiliser une installation globale, vous pouvez ajouter le package à votre
devDependencies
(--save-dev
), puis exécuter le binaire de n'importe où dans votre projet:Dans ton cas:
Cet ingénieur a fourni un
npm-exec
alias comme raccourci. Cet ingénieur utilise un shellscript appeléenv.sh
. Mais je préfère utiliser$(npm bin)
directement, pour éviter tout fichier ou configuration supplémentaire.Bien que cela rend chaque appel un peu plus grand, cela devrait simplement fonctionner , en évitant:
sudo
Désavantages:
$(npm bin)
ne fonctionnera pas sous Windows.npm bin
dossier. (Installez npm-run ou npm-which pour les trouver.)Il semble qu'une meilleure solution consiste à placer les tâches courantes (telles que la construction et la réduction) dans la section "scripts" de votre
package.json
, comme Jason le montre ci-dessus.la source
.bashrc
ajouter facilement lebin/
répertoire à votrePATH
variable d'environnement:alias nodebin='export PATH=$(npm bin)/:$PATH'
. Exécuteznodebin
et vous pouvez simplement taper vos commandes comme d'habitude.C'est un peu vieux mais je suis tombé sur l'exigence alors voici la solution que j'ai trouvée.
Le problème:
Notre équipe de développement gère de nombreux produits d'application Web .NET que nous migrons vers AngularJS / Bootstrap. VS2010 ne se prête pas facilement aux processus de construction personnalisés et mes développeurs travaillent régulièrement sur plusieurs versions de nos produits. Notre VCS est Subversion (je sais, je sais. J'essaie de passer à Git mais mon équipe marketing embêtante est si exigeante) et une seule solution VS comprendra plusieurs projets distincts. J'avais besoin de mon personnel pour avoir une méthode commune pour initialiser leur environnement de développement sans avoir à installer plusieurs fois les mêmes packages Node (gulp, bower, etc.) sur la même machine.
TL; DR:
Nécessite «npm install» pour installer l'environnement de développement global Node / Bower ainsi que tous les packages requis localement pour un produit .NET.
Les packages globaux ne doivent être installés que s'ils ne sont pas déjà installés.
Les liens locaux vers les packages globaux doivent être créés automatiquement.
La solution:
Nous avons déjà un cadre de développement commun partagé par tous les développeurs et tous les produits, j'ai donc créé un script NodeJS pour installer les packages globaux en cas de besoin et créer les liens locaux. Le script réside dans ".... \ SharedFiles" par rapport au dossier de base du produit:
Maintenant, si je veux mettre à jour un outil global pour nos développeurs, je mets à jour l'objet "packages" et j'enregistre le nouveau script. Mes développeurs le vérifient et l'exécutent avec "node npm-setup.js" ou par "npm install" à partir de l'un des produits en cours de développement pour mettre à jour l'environnement global. Le tout prend 5 minutes.
En outre, pour configurer l'environnement d'un nouveau développeur, il doit d'abord installer uniquement NodeJS et GIT pour Windows, redémarrer son ordinateur, consulter le dossier «Fichiers partagés» et tous les produits en cours de développement, et commencer à travailler.
Le "package.json" du produit .NET appelle ce script avant l'installation:
Remarques
Notez que la référence de script nécessite des barres obliques même dans un environnement Windows.
"npm ls" donnera des messages "npm ERR! extraneous:" pour tous les packages liés localement car ils ne sont pas répertoriés dans les "dépendances" de "package.json".
Modifier 29/1/16
Le
npm-setup.js
script mis à jour ci-dessus a été modifié comme suit:Le package "version" dans
var packages
est désormais la valeur "package" transmisenpm install
sur la ligne de commande. Cela a été modifié pour permettre l'installation de packages à partir d'un autre emplacement que le référentiel enregistré.Si le package est déjà installé mais n'est pas celui demandé, le package existant est supprimé et le package correct installé.
Pour des raisons inconnues, npm lancera périodiquement une erreur EBUSY (-4082) lors de l'exécution d'une installation ou d'un lien. Cette erreur est interceptée et la commande est réexécutée. L'erreur se produit rarement une deuxième fois et semble toujours disparaître.
la source
Vous pouvez utiliser un fichier séparé, comme
npm_globals.txt
, au lieu depackage.json
. Ce fichier contiendrait chaque module sur une nouvelle ligne comme celle-ci,Ensuite, dans la ligne de commande, exécutez,
Vérifiez qu'ils sont installés correctement avec,
Quant à savoir si vous devriez le faire ou non, je pense que tout dépend du cas d'utilisation. Pour la plupart des projets, ce n'est pas nécessaire; et il
package.json
est préférable que votre projet encapsule ces outils et dépendances ensemble.Mais de nos jours, je constate que j'installe toujourscreate-react-app
et d'autres CLI dans le monde lorsque je saute sur une nouvelle machine. C'est bien d'avoir un moyen simple d'installer un outil global et ses dépendances lorsque la gestion des versions n'a pas beaucoup d'importance.Et de nos jours, j'utilise
npx
, un coureur de package npm , au lieu d'installer des packages globalement.la source
Tous les modules de package.json sont installés dans ./node_modules/
Je n'ai pas pu trouver cela explicitement indiqué, mais c'est la référence package.json pour NPM .
la source
Créez votre propre script pour installer les dépendances globales. Il n'en faut pas beaucoup. package.json est assez extensible.
En utilisant ce qui précède, vous pouvez même le faire en ligne, ci-dessous!
Regardez la préinstallation ci-dessous:
Les auteurs de node peuvent ne pas admettre que package.json est un fichier projet. Mais il est.
la source