npm instalacja systemu Windows na całym świecie powoduje błąd npm! obcy


121

Jestem nowy w chrząknięciu i npm. Wypróbowuję więc „przykład książki kucharskiej” w witrynie „ http://tech.pro/tutorial/1190/package-managers-an-introductory-guide-for-the-uninitiated-front-end-developer#front_end_developers ” . Nie powinieneś teraz tam szukać, ale pomyślałem, że dobrze byłoby udostępnić tę witrynę. Na razie dobrze, dopóki nie dojdzie do globalnej instalacji. (Ok, jakieś błędy musiałem rozgryźć ale teraz mam działający npm).

Jeśli chodzi o próbę zainstalowania czegoś globalnie, utknąłem.

Co zrobiłem do tej pory, aby przetestować globalną instalację jakiegoś pakietu:

  1. Utworzono katalog testów grunttest

  2. W tym katalogu:

    npm install -g jshint

Wyjście, które widzę:

 npm http GET https://registry.npmjs.org/jshint
 npm http 304 https://registry.npmjs.org/jshint
 ...
 npm http 304 https://registry.npmjs.org/string_decoder
 C:\Program Files\nodejs\node_modules\npm\jshint -> C:\Program Files\nodejs\node_modules\npm\node_modules\jshinnt
 jshint@2.4.4 C:\Program Files\nodejs\node_modules\npm\node_modules\jshint
 ├── console-browserify@0.1.6
 ├── exit@0.1.2
 ├── underscore@1.4.4
 ├── shelljs@0.1.4
 ├── minimatch@0.2.14 (sigmund@1.0.0, lru-cache@2.5.0)
 ├── cli@0.4.5 (glob@3.2.9)
 └── htmlparser2@3.3.0 (domelementtype@1.1.1, domutils@1.1.6, domhandler@2.1.0, readable-stream@1.0.26-2)

Po prostu zdaję sobie sprawę z 304, co powinno być w porządku, ponieważ po prostu mówi, że zasób nie był modyfikowany od ostatniej instalacji (kilka minut wcześniej).

Sprawdzanie, czy jshint istnieje z:

`npm -global list`

Wynik:

npm@1.4.3 C:\Program Files\nodejs\node_modules\npm
├── abbrev@1.0.4
├── ansi@0.2.1
├─...
├──
├── graceful-fs@2.0.2
├── inherits@2.0.1
├── ini@1.1.0
├─┬ init-package-json@0.0.14
│ └── promzard@0.2.1
├─┬ jshint@2.4.4 extraneous
│ ├─┬ cli@0.4.5
│ │ └─┬ glob@3.2.9
│ │   └── inherits@2.0.1
│ ├── console-browserify@0.1.6
│ ├── exit@0.1.2
│ ├─┬ htmlparser2@3.3.0
│ │ ├── domelementtype@1.1.1
│ │ ├── domhandler@2.1.0
│ │ ├── domutils@1.1.6
│ │ └─┬ readable-stream@1.0.26-2
│ │   └─... ├── text-table@0.2.0
├── uid-number@0.0.3
└── which@1.0.5

**npm ERR! extraneous: jshint@2.4.4 C:\Program Files\nodejs\node_modules\npm\node_modules\jshint npm**

Pytania:

  1. Dlaczego otrzymuję błąd npm ERR! obce ...?
  2. Co to znaczy?
  3. Jak mogę rozwiązać ten problem?

Informacja:

Jestem na komputerze z systemem Windows 7 i używam cygwin jako powłoki. próba po prostu jshint ( jshint someTestfile.js) oczywiście nie działa.

Z góry dziękuję, Meru

Odpowiedzi:


209

npm ERR! extraneousoznacza, że ​​pakiet jest zainstalowany, ale nie ma go na liście w projekcie package.json.

Ponieważ wymieniasz pakiety, które zostały zainstalowane globalnie, spowoduje to wiele zewnętrznych błędów, które można po prostu zignorować, ponieważ większość rzeczy zainstalowanych globalnie nie będzie w twoim projekcie package.json.


1
cześć! Dziękuję za odpowiedź. Czy to również oznacza, że ​​rzeczywiście powinienem umieć wykonać "jshint", prawda?
Meru,

Poprawny. Bieganie jshint myfile.jspowinno działać na jshint myfile.js.
Kyle Robinson Young

1
O, rozumiem. Z Grunt wszystko przechodzi przez zadania. Możesz załadować i skonfigurować grunt-contrib-jshintzadanie w swoim Gruntfile.js. Jedyną rzeczą, którą instalujesz globalnie, jest npm i grunt-cli -gto, że masz dostęp do uruchomienia gruntpolecenia, aby uruchomić plik Gruntfile.js. Zobacz ten przewodnik, aby uzyskać więcej informacji: gruntjs.com/getting-started
Kyle Robinson Young

8
Jeśli masz dodatkowe biblioteki zapisane lokalnie (nie globalnie), możesz npm pruneje pozbyć.
krx

2
@KyleRobinsonYoung: Może wspomnę o tym w odpowiedzi. Możesz usunąć cały nieużywany pakiet za pomocąnpm prune --your-env
geek_guy

21

1 i 2: Oznacza to, że nie masz pliku jshint na liście w pliku package.json projektu, ale jest on zainstalowany globalnie. Nie jest to więc duży problem.

3: Aby uniknąć tego dodatkowego błędu, możesz uruchomić lub ponownie uruchomić instalację z opcją --save. Spowoduje to automatyczną aktualizację pliku package.json:

npm install -g jshint --save

Lub musisz ręcznie zaktualizować plik package.json z rozszerzeniem "dependencies": {...}


w ma przypadkach działa tylko z lokalnym bez globalnego duplikatu
BG BRUNO

2
--savenie działa razem z -g. Globalna lista pakietów nie zawiera pliku package.json.
Guido Bouman,

5

Rozwiązałem to, wykonując npm updatew folderze pakietu nadrzędnego, który usunął niektóre obce pakiety z listy, a następnie zrobił npm uninstall <package>dla pozostałych.

Wydaje się, że zadziałało, ponieważ po wykonaniu tej czynności nie pojawiają się żadne błędy.


3

Rozwiązałem to, łącząc wszystkie odpowiedzi. Najpierw zainstalowałem pakiet globalnie.

npm install -g packagename --save

Ponieważ npm zainstalował ten pakiet również globalnie, ale nie dodał go do mojego lokalnego pliku package.json, musiałem coś z tym zrobić.

Wybieram rozwiązanie polegające na usunięciu lokalnego, a następnie zainstalowaniu go globalnie.

npm uninstall packagename
npm install -g packagename

W ten sposób nie mam więcej ostrzeżeń i nie psuję pliku package.json.


Plus 100. Musiałem odinstalować lokalnie i zainstalować globalnie.
Collin Peters

1

W moim przypadku widziałem to 'npm ERR! obca '' wiadomość w moim terminalu Cygwin, kiedy zrobiłem 'npm ls'. Myślałem, że to jakiś rodzaj globalnie zepsutej konfiguracji po wielu majsterkowaniu. Dowiaduję się tutaj następujących obserwacji:

  • „npm ls” daje różne wyniki w zależności od aktualnej lokalizacji folderu.
  • „npm ls” próbuje wykryć obecność folderu „node_modules” w bieżącej lokalizacji folderu i wyświetlić jego zawartość. NIE globalne!
  • Ponadto, jeśli bieżący folder zawierający „node_modules” również zawiera plik package.json zawierający mniej modułów wymienionych w tym miejscu, zostanie wyświetlony błąd.

I „rm package.json” i „npm ls” nie wyświetla już komunikatu o błędzie. Mówię więc, że zawsze sprawdzaj bieżącą lokalizację pod kątem obecności folderu `` node_modules '' i pliku package.json, ponieważ te mają pierwszeństwo w sprawdzaniu, a jeśli ich brakuje, sprawdzanie kontynuuje do folderu nadrzędnego i tak dalej, a jeśli dużo majstrowałeś przy wielu fragmentach kodu, być może rozproszyłeś się w wielu folderach node_modules i pliku package.json. Nic nie jest tu naprawdę zepsute, w przeciwieństwie do tych doświadczeń, które mamy podczas tworzenia J2EE Java / eclipse IDE lub w dniach, kiedy musimy używać regedit do zmiany ustawień w systemie Windows.


1

W moim przypadku było to spowodowane tym, że nazwa pakietu w jego package.jsonpliku nie była taka sama jak nazwa zależności wymieniona w package.jsonmodule zależnym. Mój błąd, ponieważ jest to nowy moduł, który stworzyłem, ale trudny do wykrycia, ponieważ npm nie daje żadnej wskazówki.

Stało się tak podczas używania dependencies: { "my-module": "file:local-modules/mymodule" }składni z literówką w nazwie „mój-moduł”.


0

Wynika to z faktu, że Twojego pakietu nie ma w pliku package.json. Jeśli go dodasz, problem zostanie rozwiązany, spójrz na poniższy obrazek:

wprowadź opis obrazu tutaj

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.