NPM: Po tym, jak moduł „npm link” nie został znaleziony

89

Tworzę dwa moduły dla NodeJS, pierwszy nazwany aligatori drugi aligator-methods. Drugi zależy od pierwszego do pracy. Rozwijam te dwa moduły w tym samym czasie i chcę mieć łącze globalne, aligatoraby móc go używać tak, jak w rejestrze npm i właśnie zainstalowałem go globalnie. Aby to zrobić, dokumentacja NPM mówi, że muszę użyć, npm linkale nie działa.

Plik package.jsonmodułu 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"
  }
}

Plik package.jsonmodułu 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"
 }
}

Przede wszystkim podłączyłem moduł globalnie:

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

To, jeśli się nie mylę, stworzyło globalne odniesienie do mojego modułu aligatori teraz mogę używać tego modułu z dowolnego miejsca na komputerze.

Potem poszedłem do innego modułu i próbowałem zainstalować zależność, ale dało mi to takie wyjście:

$ 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

Próbowałem nawet połączyć to bezpośrednio z:

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

Ale to też nie zadziałało.

Jakieś przemyślenia na temat tego, co może się stać? Czytałem gdzieś, że może miało to coś wspólnego z moją instalacją node i npm, ponieważ zostało zrobione przez Homebrew, więc czasami muszę go użyć sudo, wydawało się to mało prawdopodobne, ale wypróbowałem to, co zaproponowali i też nie zadziałało.

Roc
źródło
W przesłanym kodzie nazwa pierwszego modułu jest zapisana aligtori próbujesz odnieść się do niej w drugim module jako aligator. Może to również spowodować załamanie się zależności.
Bruno Toffolo
@BrunoToffolo Tak, masz rację, ale w tym przypadku był to błąd ortograficzny w poście. Poprawiłem to, dzięki.
Roc
straciłem 4 godziny mojego nieszczęśliwego życia w konfiguracji webpacka do oszukiwania: / Uratowałeś mi życie! +1
Tom Sarduy
8
Wow, miałem ten sam problem z mainmoim package.json, dziękuję za zaktualizowanie odpowiedzi z poprawką!
mattyb
jeśli znalazłeś odpowiedź, dobrym pomysłem byłoby opublikowanie jej jako odpowiedzi i ustawienie pytania jako rozwiązanego z tym :)
Alberto S.

Odpowiedzi:

39

Napotkałem ten problem z powodu NVM, uruchomiłem jedną wersję węzła dla zależności, a drugą dla zależności.

linuxdan
źródło
1
Czy Ty lub ktokolwiek inny może podać link do lokalizacji, w której można rozwiązać ten przypadek?
Kevin Danikowski
4
W moim przypadku muszę uruchomić 'nvm use <VERSION>' na obu pakietach, gdzie WERSJA była taka sama dla obu pakietów.
linuxdan
29

Usunięcie, package-lock.jsona następnie ponowne uruchomienie npm installrozwiązało problem.

Sean Inge Asbjørnsen
źródło
2
To mogłoby rozwiązać obecny problem, ale prawdopodobnie stworzy kilka poważniejszych. pliki blokady odgrywają bardzo ważną rolę i nie należy ich usuwać. Krótko mówiąc: to mechanizmy, które zapewniają, że każdy członek zespołu używa dokładnie tych samych zależności. Możesz sprawdzić tę odpowiedź na przepełnieniu stosu: stackoverflow.com/questions/54124033/… Ale przeczytanie powodu, dla którego istnieje w dokumentacji, to również dobry początek. docs.npmjs.com/files/package-lock.json
SKuijers
Byłbym skłonny podnieść tę odpowiedź, gdyby była pogrubiona notatka wskazująca, że ​​powinna to być całkowicie ostateczność. Jak wskazuje @SKuijers, pliki blokady odgrywają kluczową rolę w utrzymywaniu wersji zależności. Prawdopodobnie wersje zależności zostały również zablokowane package.json, ale przez większość czasu widzę, że to package-lock.jsonlub yarn.lockbyli strażnikami tego.
FrostyDog
29

Problem polegał na tym, że mainwłaściwość package.jsonwskazywała na nieistniejący plik. Wygląda na to, że problem może się zdarzyć z wielu powodów, więc zapoznaj się z innymi odpowiedziami.

Roc
źródło
omg, chcę zagłosować za tym 50 razy i spojrzeć na siebie raz za każdy głos za.
Ben
Ciekawe, że projekt wymaga main. Przeważnie robiłem bez tego, ale myślę, że stwarza te drobne problemy.
cst1992
Niezłe znalezisko! Widziałem twoją odpowiedź i od razu wiedziałem, że to mój problem :).
slashp
11

Przy pierwszym uruchomieniu npm linkz aligatorkatalogu tworzysz łącze z globalnego katalogu node_modules do aligator. Następnie, gdy uruchamiasz npm link aligatorz aligator-methodskatalogu, łączysz się aligatorz lokalnie zainstalowanymi modułami node_modules do oryginalnego źródła (jak widać w powyższym przykładzie). Gdy to zrobisz, nie powinno być już potrzeby instalacji, ponieważ jest już „zainstalowany”. Jakie błędy widzisz po uruchomieniu npm link aligatorpolecenia?

Jeśli chcesz tylko zainstalować zależność z katalogu lokalnego, możesz po prostu spróbować użyć npm installzamiast tego. Na przykład:

$ cd ~ / aligator-methods
$ npm install ../aligator

dylanty
źródło
5
Dziękujemy za Twój wysiłek w celu rozwiązania tego problemu. Mój npm linknie pokazał żadnych błędów. Problem w moim przypadku polegał na tym, że właściwość mainwskazywała na nieistniejący plik. Co do mojego npm install, masz rację, nie musiałem niczego instalować, wszystko npm linkrobi. Dzięki za to, że o tym nie wiedziałem.
Roc,
1
Mam ten sam problem, ale nie znalazłem rozwiązania ... jeśli spróbuję indywidualnie zażądać każdego połączonego pakietu, wszystkie oprócz jednego działają ... ten, który nie działa, wyświetla tylko komunikat: „Błąd: nie można znaleźć modułu modułu” -i-właśnie-połączone '".
Michael,
@Michael wygląda na to, że miałem moduł zagnieżdżony w głębszym katalogu, który próbował "dynamicznie" wymagać modułu, który się nie udał (tj. Nazwa ciągu przekazanego do require () została przekazana do modułu), dlatego musiałem npm link do głębszego katalogu.
Michael
4

Mój problem polegał na tym, że repozytorium A było używane, npma repozytorium B yarn, więc musiałem uruchomić yarn linkrepozytorium B, aby wciągnąć go przez npm link package-namerepozytorium A.

FrostyDog
źródło
Ty, panie, sprawiłeś, że mój dzień! Dzięki
Alec
2

Napraw moją wersję tego problemu; w npm v5.3.0 usunąłem node_modulesz repozytorium, w którym łączyłem się z innym projektem.

Dowiedziałem się, że po npm v3 próbują umieścić wszystkie zależności node_modules w jednym katalogu node_modules (jeden w twoim projekcie), aby maksymalnie spłaszczyć strukturę ( http://codetunnel.io/npm-5-changes-to-npm -link / ).

crollywood
źródło
2

Dla mnie zadziałało:

  1. Usuń node_moduleszarówno moduł zależności, jak i modułu konsumenta.
  2. Biegać npm unlink --no-save [dependency-module]
  3. ponownie połącz za pomocą poleceń 2-link zgodnie z npm-link

Teraz mogę w pełni przetestować lokalnie mój niepublikowany moduł.

Dodatkowo istnieje polecenie npm pack, które może pomóc w testowaniu niepublikowanych modułów, chociaż nie jest tak solidne.

npm-pack

SandeepJ
źródło
1

U mnie stało się tak, gdy zmniejszyłem numer wersji mojego pakietu lokalnego z 0.1.0 do 0.0.1. A w projektach, w których łączyłem się z tym pakietem, nadal korzystałem z wyższego numeru wersji. Aktualizacja zależności w package.jsonnaprawiona.

Flion
źródło
0

Podczas korzystania z peerDependency

Tworzę dwa pakiety stejs, i stejs-loader. stejs-loaderma stejsjako peerDependency. Kiedy biegałem npm link stejs-loaderiw npm link stejsmoim projekcie otrzymywałem błąd, stejs-loaderktórego nie mogłem znaleźć stejs. Naprawiłem to, uruchamiając npm link stejsw katalogu stejs-loader.

ItsaMeTuni
źródło
0

Sprawdź tsconfig moduleResolution

Jeśli tak jak ja zdarzyło ci się zmienić tsconfig modulez es5na esnextlub coś, to plikmoduleResolution domyślne mogło się zmienić.

Bez moduleResolution ustawienia na „węzeł”, Typecript nie rozwiąże pakietów node_modules.

Możesz przeczytać na stronie Opcje kompilatora o tym, jak wartość domyślna zależy od wartości module, której wartość domyślna z kolei zależy target- ale prawdopodobnie jawnie ustaw ją na „węzeł”.

Matthias
źródło