NPM: après le module «npm link» est introuvable

89

Je développe deux modules pour NodeJS, le premier nommé aligatoret le second aligator-methods. Le deuxième dépend du premier à travailler. Je développe ces deux modules en même temps et je souhaite créer un lien global aligatorpour pouvoir l'utiliser comme sur le registre npm et je viens de l'installer globalement. Pour faire cette documentation NPM dit que je dois utiliser npm linkmais cela ne fonctionne pas.

Fichier package.jsondu module aligator:

{
  "name": "aligator",
  "version": "0.0.1",
  "description": "",
  "main": "index.js",
  "private": true,
  "directories": {
    "doc": "docs",
    "example": "examples",
    "test": "spec"
  },
  "scripts": {
    "test": "gulp jasmine"
  },
  "license": "MIT",
  "devDependencies": {
    "gulp": "^3.6.2",
    "gulp-jasmine": "^0.2.0",
    "gulp-jshint": "^1.6.1",
    "gulp-rename": "^1.2.0",
    "jasmine-node": "^1.14.3"
  },
  "dependencies": {
    "bluebird": "^1.2.4",
    "lodash": "^2.4.1",
    "mathjs": "^0.22.0"
  }
}

Fichier package.jsondu module aligator-methods:

{
 "name": "aligator-methods",
 "version": "0.0.1",
 "description": "",
 "main": "index.js",
 "private": true,
 "directories": {
   "doc": "docs",
   "example": "examples",
   "test": "jasmine"
 },
 "scripts": {
   "test": "gulp jasmine"
 },
 "author": "",
 "license": "MIT",
 "devDependencies": {
   "gulp": "^3.6.2",
   "gulp-jasmine": "^0.2.0",
   "gulp-jshint": "^1.6.1",
   "gulp-rename": "^1.2.0",
   "jasmine-node": "^1.14.3"
 },
 "dependencies": {
   "lodash": "^2.4.1",
   "mathjs": "^0.22.0",
   "aligator": "^0.0.1"
 }
}

Tout d'abord, j'ai lié le module globalement:

$ cd ~/aligator
$ npm link
/usr/local/lib/node_modules/aligator -> /Users/roc/aligator

Ceci si je ne me trompe pas a créé une référence globale de mon module aligatoret maintenant je peux utiliser ce module de partout où je veux dans l'ordinateur.

Ensuite, je suis allé à l'autre module et j'ai essayé d'installer la dépendance mais cela m'a donné cette sortie:

$ cd ~/aligator-methods
$ npm install
npm ERR! 404 404 Not Found: aligator
npm ERR! 404
npm ERR! 404 'aligator' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it
npm ERR! 404 It was specified as a dependency of 'aligator-methods'
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, or http url, or git url.

npm ERR! System Darwin 13.2.0
npm ERR! command "node" "/usr/local/bin/npm" "install"
npm ERR! cwd /Users/roc/aligator-methods
npm ERR! node -v v0.10.28
npm ERR! npm -v 1.4.16
npm ERR! code E404
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     /Users/roc/aligator-methods/npm-debug.log
npm ERR! not ok code 0

J'ai même essayé de le lier directement avec:

$ cd ~/aligator-methods
$ npm link aligator
/Users/roc/aligator-methods/node_modules/aligator -> /usr/local/lib/node_modules/aligator -> /Users/roc/aligator

Mais cela n'a pas fonctionné non plus.

Des pensées sur ce qui pourrait se passer? J'ai lu quelque part que cela avait peut-être quelque chose à voir avec mon installation de node et npm parce qu'il a été fait par Homebrew et que parfois j'ai besoin de l'utiliser sudo, cela semblait peu probable mais j'ai essayé ce qu'ils proposaient et cela n'a pas fonctionné non plus.

node.js  npm 
— Roc
source
Dans le code publié, le nom du premier module est épelé aligtoret vous essayez de vous y référer dans le deuxième module comme aligator. Cela peut également faire planter votre dépendance.
— Bruno Toffolo
@BrunoToffolo Oui, vous avez raison, mais, dans ce cas, c'était juste une faute d'orthographe dans le message. Je l'ai corrigé, merci.
— Roc
perdu 4 heures de ma vie misérable en trompant la configuration du webpack: / Vous m'avez sauvé la vie! +1
— Tom Sarduy
8
Wow j'ai eu le même problème avec le mainde mon package.json, merci d'avoir mis à jour la réponse avec votre correctif!
— mattyb
si vous avez trouvé la réponse, ce serait une bonne idée de la publier comme réponse et de définir la question comme résolue avec celle-là :)
— Alberto S.

Réponses:

39

J'ai rencontré ce problème à cause de NVM, j'utilisais une version de nœud pour la dépendance et une autre pour la personne à charge.

— linuxdan
source
1
Pouvez-vous ou quelqu'un d'autre un lien vers un endroit où résoudre ce problème par hasard?
— Kevin Danikowski
4
Dans mon cas, je dois exécuter 'nvm use <VERSION>' sur les deux packages, où VERSION était la même pour les deux packages.
— linuxdan
29

La suppression package-lock.jsonpuis la réexécution ont npm installrésolu le problème pour moi.

— Sean Inge Asbjørnsen
source
2
Cela pourrait résoudre le problème actuel, mais peut-être en créer de plus gros. Les fichiers de verrouillage jouent un rôle très important et ne doivent pas être supprimés. En bref: ce sont les mécanismes qui garantissent que chaque membre de l'équipe utilise exactement les mêmes dépendances. Vous pouvez consulter cette réponse sur le débordement de pile: stackoverflow.com/questions/54124033/... Mais lire la raison pour laquelle il existe dans la documentation est également un bon début. docs.npmjs.com/files/package-lock.json
— SKuijers
Je serais prêt à augmenter cette réponse s'il y avait une note en gras indiquant que cela devrait être un tout dernier recours. Comme le souligne @SKuijers, les fichiers de verrouillage jouent un rôle essentiel dans le maintien des versions de dépendance. Vraisemblablement, les versions de dépendance ont également été verrouillées dans le package.json, mais la plupart du temps, je vois que le package-lock.jsonou yarn.lockont été les gardiens de cela.
— FrostyDog
29

Le problème était que la mainpropriété de package.jsonpointait vers un fichier inexistant. Il semble que le problème puisse survenir pour plusieurs raisons, alors assurez-vous de jeter un coup d'œil à d'autres réponses.

— Roc
source
omg je veux voter pour 50 fois et facepalm moi-même une fois pour chaque vote positif.
— Ben
Intéressant de savoir que le projet nécessite main. La plupart du temps, je m'en suis passé, mais je suppose que cela crée ces problèmes mineurs.
— cst1992
Bonne trouvaille! J'ai vu votre réponse et j'ai tout de suite su que c'était mon problème :).
— slashp du
11

Lorsque vous exécutez pour la première fois à npm linkpartir du aligatorrépertoire, vous créez un lien à partir de votre répertoire global node_modules vers aligator. Ensuite, lorsque vous exécutez le à npm link aligatorpartir du aligator-methodsrépertoire, vous aligatorcréez un lien depuis vos node_modules installés localement vers la source d'origine (comme le montre la sortie dans votre exemple ci-dessus). Une fois cela fait, il ne devrait plus être nécessaire d'installer car il est déjà "installé". Quelles erreurs voyez-vous après avoir exécuté la npm link aligatorcommande?

Si vous souhaitez simplement installer une dépendance à partir d'un répertoire local, vous pouvez simplement essayer d'utiliser à la npm installplace. Par exemple:

$ cd ~ / méthodes d'aligator
$ npm install ../aligator

— dylants
source
5
Merci pour vos efforts pour résoudre ce problème. Mon npm linkn'a montré aucune erreur. Le problème dans mon cas était que la propriété mainpointait vers un fichier inexistant . Quant à moi, npm installvous avez raison, je n'ai pas besoin d'installer quoi npm linkque ce soit pour tout faire. Merci pour ça, je ne le savais pas.
— Roc
1
J'ai le même problème, mais je n'ai pas trouvé de solution ... si j'essaie d'exiger individuellement chaque package lié, tous sauf un fonctionnent ... celui qui ne fonctionne pas dit simplement: "Erreur: module de module introuvable -i-juste-lié '".
— Michael
@Michael semble avoir un module imbriqué dans un répertoire plus profond qui essayait d'exiger "dynamiquement" le module qui échouait (c'est-à-dire que le nom de la chaîne passée à require () était passé au module), donc je devais npm lien dans le répertoire plus profond.
— Michael
4

Mon problème a finalement été que le repo A utilisait npmet le repo B utilisait yarn, donc je devais exécuter yarn linkdans le repo B afin de le récupérer via le npm link package-namerepo A.

— FrostyDog
source
Vous, monsieur, avez fait ma journée! Merci
— Alec le
2

Correctif pour ma version de ce problème; dans npm v5.3.0, j'ai supprimé node_modulesdu repo que je liais à un autre projet.

J'ai découvert qu'après npm v3, ils essayaient de mettre toutes les dépendances node_modules dans un répertoire node_modules (un dans votre projet) pour aplatir la structure autant que possible ( http://codetunnel.io/npm-5-changes-to-npm -link / ).

— Crollywood
source
2

Ce qui a fonctionné pour moi était de:

  1. Supprimez le node_modulesdans la dépendance et le module consommateur.
  2. Courir npm unlink --no-save [dependency-module]
  3. re-link avec les commandes 2-link selon npm-link

Maintenant, je suis en mesure de tester entièrement mon module non publié localement.

De plus, il existe une commande npm pack qui peut vous aider à tester vos modules non publiés, mais pas aussi robustes.

npm-pack

— SandeepJ
source
1

Pour moi, cela s'est produit lorsque j'ai diminué le numéro de version de mon package local de 0.1.0 à 0.0.1. Et dans les projets où j'ai lié à ce package, j'utilisais toujours le numéro de version le plus élevé. La mise à jour des dépendances a été package.jsoncorrigée.

— Flion
source
0

Lors de l'utilisation de peerDependency

Je développe deux packages stejs, et stejs-loader. stejs-loadera stejscomme un peerDependency. Quand j'ai couru npm link stejs-loaderet npm link stejsdans mon projet, j'obtenais une erreur qui stejs-loaderne pouvait pas être trouvée stejs. Je l'ai réparé en exécutant npm link stejsdans le répertoire de stejs-loader.

— ItsaMeTuni
source
0

Vérifiez le module tsconfig

Si, comme moi, vous avez changé le tsconfig modulede es5à esnextou quelque chose, alors la moduleResolutionvaleur par défaut a peut-être changé.

Sans moduleResolutionêtre défini sur "node", le typecript ne résoudra pas les packages node_modules.

Vous pouvez lire sur la page Options du compilateur comment la valeur par défaut dépend de la valeur de module, dont la valeur par défaut dépend à son tour target- mais définissez-la probablement sur "node" explicitement.

— Matthias
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.