Comment résoudre le problème de dépendance globale du module NPM

Node Package Manager (NPM) fournit aux développeurs Web de nombreux modules JavaScript pratiques, simplifiant considérablement la recherche et la gestion des dépendances des applications. Il facilite également que les développeurs à créer et à publier leurs propres modules, que d'autres développeurs peuvent facilement obtenir et utiliser avec simplement npm install -g your-tool. Cela semble parfait, non?

euh, en fait ... ce n'est pas le cas.

Points clés

• La réduction de l'utilisation de l'option -g pour installer les modules NPM peut causer des problèmes car même si le projet dépend des modules globaux, ces modules ne sont pas répertoriés comme dépendances pour le projet. Cela augmente la charge de travail d'autres personnes utilisant l'application et peut conduire à des conflits de version.
• Pour éviter les problèmes causés par les dépendances globales du module NPM, il est recommandé de supprimer -g lors de l'installation du module et de le remplacer par --save-dev. Cela enregistre le module en tant que dépendance de développement et s'assure qu'il est installé lors de l'exécution npm install.
• Après avoir installé les dépendances localement, tous les scripts qui sont destinés à être exécutés à partir de la ligne de commande seront placés dans le répertoire ./node_modules/.bin/. L'utilisation de scripts NPM peut simplifier ce processus et permettre à la version locale du module d'exécuter avec des commandes plus courtes.
• Bien qu'il soit un peu redondant, il est recommandé d'utiliser le nœud et le NPM comme dépendances pour le projet et les installer localement dans le projet. Cependant, cela peut être compliqué car le nœud est différent sur chaque système d'exploitation, et il n'y a pas de moyen facile de s'assurer que tout le monde ajoute les chemins de copie locaux du nœud et du NPM à leurs variables d'environnement de chemin.

Nous avons eu quelques problèmes

Je ne dirai pas de ne jamais installer le module NPM en utilisant l'option -g, mais je dois dire que la surutilisation peut causer des problèmes. Je pense que nous devons réduire l'utilisation de l'installation mondiale des modules, en particulier dans le cas des outils de vérification de build, de test ou de code (tels que Gulp, Karma, Jshint, etc.), pour les raisons suivantes: cet article discute principalement de Gulp car il est Très populaire et se lit bien décontracté, mais si vous n'aimez pas Gulp, remplacez-le simplement dans votre esprit par tout outil que vous aimez.

Tout d'abord, les modules mondiaux ne sont pas répertoriés comme des dépendances pour les projets, ce qui augmente la charge de travail d'autres personnes utilisant votre application même si vos projets en dépendent. Vous savez que vous devez utiliser Gulp pour préparer l'environnement de production de votre projet, donc vous l'installez et l'utilisez à l'échelle mondiale. Lorsque d'autres veulent commencer à utiliser ou à travailler sur votre excellent projet open source, ils ne peuvent pas simplement taper npm install et commencer à travailler. Vous devrez éventuellement ajouter des instructions dans le fichier ReadMe, par exemple:

Pour utiliser ce projet, suivez ces étapes:

• Git Clone Warehouse
• Run npm install
• Run npm install -g gulp
• Run gulp build

J'ai vu deux problèmes: d'abord, vous avez ajouté les étapes supplémentaires pour installer Gulp à l'échelle mondiale; J'ai vu une étape supplémentaire qui aurait pu être évitée (installation globale de Gulp), et j'ai vu que les utilisateurs doivent savoir que votre application utilise Gulp pour construire le projet. Cet article traite principalement du premier numéro, et bien que le deuxième numéro ne soit pas si grave, vous devrez mettre à jour les instructions si vous finissez par changer l'outil. La solution dont je discuterai plus loin devrait résoudre les deux problèmes.

Le deuxième problème majeur lié à l'installation de modules à l'échelle mondiale est que vous pouvez rencontrer des conflits en raison de la mauvaise version du module installé. Les deux exemples suivants illustrent ceci:

• Vous avez créé votre projet il y a six mois lorsque vous avez utilisé la dernière version de Gulp. Aujourd'hui, quelqu'un a cloné le référentiel de votre projet et a essayé d'exécuter Gulp pour le construire, mais a rencontré une erreur. En effet, la personne qui clonage votre projet exécute une ancienne version de Gulp ou une version plus récente de Gulp avec des différences significatives.
• Vous avez créé un projet en utilisant Gulp il y a six mois. Depuis lors, vous êtes allé à d'autres projets et mis à jour Gulp sur votre machine. Maintenant que vous retournez à cet ancien projet et essayez d'exécuter Gulp, vous obtiendrez une erreur car vous avez mis à jour Gulp depuis la dernière fois que le projet a contacté le projet. Maintenant, vous êtes obligé de mettre à jour le processus de construction pour travailler avec une nouvelle version de Gulp avant de pouvoir faire plus de progrès sur votre projet plutôt que de le retarder à un moment plus pratique.

Ces problèmes peuvent être très graves. Mais, comme je l'ai déjà dit, je ne dirai pas en général que vous n'installez jamais quelque chose dans le monde. Il y a quelques exceptions.

Remarque courte sur la sécurité

Par défaut, sur certains systèmes, l'installation globale des modules NPM nécessite des autorisations élevées. Si vous vous retrouvez à exécuter une commande comme sudo npm install -g a-package, vous devez modifier cette commande. Notre guide pour débutants NPM vous montrera comment le faire.

Exceptions

Alors, que pouvez-vous installer à l'échelle mondiale? En bref: tout ce sur quoi votre projet ne dépend pas. Par exemple, j'ai installé un module global appelé local-web-server. Chaque fois que j'ai juste besoin de visualiser certains fichiers HTML dans mon navigateur, j'exécute ws (c'est la commande pour local-web-server) qui définit le dossier actuel sur la racine de localhost:8000 et puis je peux y ouvrir n'importe quel document dans votre navigateur et testez-le.

J'ai également rencontré des situations où je veux compresser des fichiers JavaScript qui ne font pas partie du projet, ou du moins pas le projet qui me permet de configurer un processus de construction formel (pour des raisons stupides de "société"). Pour ce faire, j'ai installé uglify-js et je peux facilement compresser n'importe quel script à partir de la ligne de commande en secondes.

Solution

Comment devons-nous l'empêcher maintenant que nous savons où le problème peut se produire? La première chose que vous devez faire est de supprimer -g lors de l'installation du module. Vous devez le remplacer par --save-dev afin que vous puissiez enregistrer le module en tant que dépendance de développement et qu'il sera toujours installé lorsque quelqu'un s'exécute npm install. Cela ne résoudra que l'un des problèmes mineurs que j'ai mentionnés plus tôt, mais ce n'est que le début.

Ce que vous devez savoir, c'est que lorsque vous installez les dépendances localement, s'il a des scripts qui sont destinés à s'exécuter à partir de la ligne de commande, ils seront placés dans le répertoire ./node_modules/.bin/. Alors maintenant, si vous installez simplement Gulp localement, vous pouvez l'exécuter en tapant ./node_modules/.bin/gulp sur la ligne de commande. Bien sûr, personne ne veut taper tout cela. Vous pouvez utiliser les scripts NPM pour résoudre ce problème.

Dans votre fichier package.json, vous pouvez ajouter un attribut scripts similaire à ce qui suit:

<code class="language-json">{
    ...
    "scripts": {
        "gulp": "gulp"
    }
}</code>

Vous pouvez maintenant exécuter npm run gulp à tout moment pour exécuter la version locale de Gulp. Le script NPM recherche une copie locale de la commande exécutable dans le répertoire ./node_modules/.bin/ avant de vérifier la variable d'environnement de chemin. Si vous le souhaitez, vous pouvez même transmettre d'autres paramètres à Gulp en ajoutant -- avant ces paramètres, par exemple npm run gulp -- build-dev est équivalent à gulp build-dev.

Vous devez toujours taper plus que l'utilisation de Gulp à l'échelle mondiale, mais c'est mauvais, mais il existe deux façons de résoudre ce problème. La première approche (également résolu l'un des problèmes mentionnés ci-dessus) consiste à créer un alias à l'aide de scripts NPM. Par exemple, vous n'avez pas à lier votre application à Gulp, afin que vous puissiez créer des scripts qui exécutent Gulp mais ne mentionnez pas Gulp:

<code class="language-json">{
    ...
    "scripts": {
        "build": "gulp build-prod",
        "develop": "gulp build-dev"
    }
}</code>

De cette façon, vous pouvez passer des appels à glober plus courts et garder vos scripts universels. En gardant la polyvalence, vous pouvez toujours retirer de manière transparente Gulp et la remplacer par autre chose sans que personne n'ait besoin de savoir (à moins qu'il ne traite le processus de construction, auquel cas il devrait déjà le savoir et devrait probablement être impliqué dans la migration et laisser la discussion de Gulp ). Alternativement, vous pouvez même y ajouter un script postinstall afin que le processus de construction soit automatiquement exécuté immédiatement après que quelqu'un fonctionne npm install. Cela simplifiera considérablement vos fichiers ReadMe. De plus, en utilisant des scripts NPM, toute personne clonage de votre projet devrait obtenir une documentation simple et simple sur tous les processus que vous exécutez sur votre projet dans le fichier package.json.

En plus d'utiliser les scripts NPM, il existe une autre astuce qui vous permet d'utiliser l'installation locale des outils de ligne de commande: par rapport au chemin. J'ai ajouté ./node_modules/.bin/ à ma variable d'environnement de chemin, donc tant que je suis à la racine du projet, je peux accéder à l'outil de commande en tapant le nom de la commande. J'ai appris cette astuce à partir de commentaires sur un autre article que j'ai écrit (grâce à Gabriel Falkenberg).

Ces astuces ne sont pas entièrement remplacées pour chaque situation où vous souhaitez utiliser des outils comme Gulp, ils prennent du travail à mettre en place, mais je pense que la liste de ces outils car vos dépendances devraient être une meilleure pratique. Cela empêchera les conflits de version (ce qui est l'une des principales raisons des gestionnaires de dépendances en premier lieu) et aidera à simplifier les étapes dont les autres ont besoin pour obtenir votre projet.

Aller plus loin

Cela peut être un peu redondant, mais je pense que le nœud et le NPM sont également des dépendances pour votre projet, et ils ont plusieurs versions différentes qui peuvent être confrontées. Si vous souhaitez vous assurer que votre application fonctionne pour tout le monde, vous avez besoin d'un moyen de vous assurer que l'utilisateur a également la bonne version de nœud et de NPM installé.

Vous pouvez installer des copies locales de nœud et de npm dans votre projet! Mais cela ne résout pas tous les problèmes. Tout d'abord, le nœud est différent sur chaque système d'exploitation, donc tout le monde doit encore s'assurer qu'ils téléchargent une version compatible avec leur système d'exploitation. Deuxièmement, même s'il existe un moyen d'installer un nœud commun, vous devez vous assurer que tout le monde a un moyen facile d'accéder au nœud et au NPM à partir de sa ligne de commande, comme s'assurer que tout le monde ajoute le chemin à la copie locale du nœud et du NPM à leurs variables d'environnement de chemin. Il n'y a pas de moyen facile de garantir cela.

Ainsi, même si j'aimerais pouvoir appliquer une version spécifique de nœud et de NPM pour chaque projet, je ne peux pas penser à une bonne façon de le faire. Si vous pensez que c'est une bonne idée et que vous trouvez une bonne solution, faites-nous savoir dans les commentaires. J'aimerais voir une solution assez simple pour en faire une pratique standard!

Conclusion

J'espère que vous pourrez maintenant comprendre l'importance des dépendances versées qui répertorient les outils comme des projets. J'espère également que vous êtes prêt à travailler dur pour mettre en œuvre ces pratiques dans vos propres projets afin que nous puissions les promouvoir en standard. Sauf si vous avez une meilleure idée, dites-le et faites-le savoir le monde entier!

FAQS (FAQ) sur les questions de dépendances du module NPM global

Quel est le problème global de dépendance du module NPM?

Les problèmes de dépendance du module NPM global sont un problème courant que les développeurs rencontrent lors de l'installation du package Node.js à l'échelle mondiale. Ce problème se produit lorsque le package global installé ne peut pas accéder à ses dépendances installées localement. Cela peut entraîner des erreurs et des problèmes dans la fonctionnalité de l'application. Le problème est dû à la façon dont Node.js gère l'analyse du module, qui peut être très complexe et déroutant pour les développeurs.

Comment résoudre le problème des dépendances globales des modules NPM?

Il existe plusieurs façons de résoudre le problème global de dépendance du module NPM. L'un des moyens les plus efficaces est d'installer le package localement, pas dans le monde. Cela garantit que le package a accès à toutes ses dépendances. Une autre façon consiste à utiliser la commande npm link, qui crée un lien symbolique entre le package global et ses dépendances locales. Cela permet aux packages globaux d'accéder à leurs dépendances tout comme ils sont installés à l'échelle mondiale.

Quelle est la différence entre l'installation du package Node.js globalement et localement?

Lorsque vous installez le package Node.js à l'échelle mondiale, il est installé à l'emplacement central de votre système et peut être accessible par toutes les applications Node.js. D'un autre côté, lorsque vous installez le package localement, il est installé dans le répertoire node_modules de votre projet actuel, et seul ce projet peut y accéder. Bien que l'installation globale soit pratique, elle peut entraîner des problèmes globaux de dépendances du module NPM.

Quelle est la commande npm link et comment fonctionne-t-elle?

La commande

npm link est un outil fourni par NPM pour créer des liens symboliques entre les packages globaux et leurs dépendances locales. Lorsque vous exécutez npm link dans le répertoire du package, il crée un lien symbolique du répertoire global node_modules au package local. Cela permet aux packages globaux d'accéder à leurs dépendances tout comme ils sont installés à l'échelle mondiale.

Pourquoi le problème global de dépendance du module NPM se produit-il?

Le problème global de dépendance du module NPM est causé par la façon dont Node.js gère l'analyse du module. Lorsque le package est installé à l'échelle mondiale, Node.js recherche ses dépendances dans le répertoire global node_modules. Cependant, si les dépendances sont installées localement, Node.js ne peut pas les trouver, ce qui résulte des problèmes globaux de dépendances du module NPM.

Puis-je éviter les problèmes globaux de dépendance du module NPM en installant le package localement?

Oui, l'un des moyens les plus efficaces d'éviter les problèmes mondiaux de dépendances du module NPM est d'installer toujours le package localement. Cela garantit que ces packages ont accès à toutes leurs dépendances. Cependant, cela peut ne pas toujours être pratique ou pratique, surtout si vous devez utiliser le package dans plusieurs projets.

Y a-t-il un outil ou un package qui peut m'aider à gérer mes dépendances Node.js?

Oui, il existe plusieurs outils et packages qui peuvent vous aider à gérer vos dépendances Node.js. Par exemple, NPM lui-même fournit plusieurs commandes, telles que npm install, npm update, et npm outdated, ce qui peut vous aider à gérer vos dépendances. Il existe également des outils tiers tels que le fil et le greenkeeper, qui fournissent des fonctionnalités supplémentaires.

Quels sont les risques de ne pas résoudre le problème global de dépendance du module NPM?

Si le problème global de dépendance du module NPM n'est pas résolu, il peut entraîner des erreurs et des problèmes de fonctionnalité d'application. Il rend également difficile la gestion et la mise à jour des dépendances, entraînant des risques de sécurité potentiels et des packages obsolètes.

Le problème de dépendance globale du module NPM affectera-t-il les performances de mon application?

Oui, les problèmes globaux de dépendance au module NPM peuvent affecter les performances de l'application. Si le package ne peut pas accéder à ses dépendances, elle peut ne pas fonctionner correctement ou efficacement. Cela peut entraîner des problèmes de performances et des erreurs dans l'application.

Comment vérifier si le package est installé globalement ou localement?

Vous pouvez utiliser la commande npm list pour vérifier si le package est installé globalement ou localement. Si vous exécutez npm list -g, il affichera tous les packages installés à l'échelle mondiale. Si vous exécutez npm list dans le répertoire du projet, il affichera tous les packages installés localement pour le projet.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!