o npm windows install globalmente resulta em npm ERR! estranho


121

Eu sou novo para grunhir e npm. Então, eu estou tentando alguns "exemplos de livros de receitas" no site ' http://tech.pro/tutorial/1190/package-managers-an-introductory-guide-for-the-uninitiated-front-end-developer#front_end_developers ' . Você não deveria procurar lá agora, mas achei que seria bom compartilhar o site. Até aí tudo bem, até a instalação global. (Ok, alguns erros eu tive que descobrir, mas agora tenho npm em funcionamento).

Quando se trata de tentar instalar algo globalmente, fico preso.

O que fiz até agora para testar globalmente a instalação de algum pacote:

  1. Diretório de teste criado grunttest

  2. Dentro desse diretório:

    npm install -g jshint

Saída eu posso ver:

 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)

Acabei de perceber o 304, que deve estar ok, devido a apenas dizer que o recurso não foi modificado desde a última instalação (alguns minutos antes).

Verificando se o jshint existe com:

`npm -global list`

Resultado:

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**

Questões:

  1. Por que eu recebo o npm ERR! estranho ...?
  2. O que isso significa?
  3. Como posso resolver esse problema?

Em formação:

Estou no Windows 7 de uma máquina Windows, usando o cygwin como shell. tentar apenas o jshint ( jshint someTestfile.js), é claro, não funciona.

Agradecemos antecipadamente, Meru

Respostas:


208

npm ERR! extraneoussignifica que um pacote está instalado, mas não está listado no seu projeto package.json.

Como você está listando pacotes que foram instalados globalmente, isso fornecerá muitos erros estranhos que podem ser simplesmente ignorados, porque a maioria das coisas instaladas globalmente não estará no seu projeto package.json.


1
Oi! Obrigado pela resposta. Isso significa também que eu, de maneira aguda, deveria ser capaz de executar o "jshint", correto?
Meru

Corrigir. A execução jshint myfile.jsdeve executar o jshint myfile.js.
Kyle Robinson Young

1
Ah entendo. Com Grunt, tudo passa por tarefas. Você carregaria e configuraria a grunt-contrib-jshinttarefa no seu Gruntfile.js. A única coisa que você instala globalmente é o npm i grunt-cli -gque lhe dá acesso para executar o gruntcomando para executar a Gruntfile.js. Consulte este guia para obter mais informações: gruntjs.com/getting-started
Kyle Robinson Young

8
Se você tiver bibliotecas estranhas salvas localmente (não globalmente), poderá executar npm prunepara se livrar delas.
KRX

2
@KyleRobinsonYoung: Que tal mencionar isso em resposta. Você pode remover todos os pacotes não utilizados usandonpm prune --your-env
geek_guy 15/11/2015

21

1 e 2: significa que você não possui o jshint listado no arquivo package.json do seu projeto, mas que está instalado globalmente. Portanto, não é um grande problema.

3: Para evitar este estranho erro, você pode executar ou re-executar a instalação com a opção --save. Isso atualizará automaticamente o arquivo package.json:

npm install -g jshint --save

Ou precisa atualizar manualmente o arquivo package.json com um "dependencies": {...}


em casos ma funciona apenas com o local com nenhuma duplicata mundial
BG BRUNO

2
--savenão funciona junto com -g. A lista global de pacotes não possui um package.json.
Guido Bouman

5

Eu resolvi isso fazendo um npm updatena pasta do pacote pai, que removeu alguns dos pacotes estranhos da lista e depois o fez npm uninstall <package>para os poucos restantes.

Parece ter funcionado, pois não estou recebendo erros depois de fazer isso.


3

Eu o resolvi combinando todas as respostas. Inicialmente, instalei o pacote globalmente.

npm install -g packagename --save

Como o npm instalou esse pacote também globalmente, mas não o adicionou ao meu arquivo package.json local, tive que fazer algo a respeito.

Eu escolho, a solução para remover a local e depois instalá-la globalmente.

npm uninstall packagename
npm install -g packagename

Dessa forma, não tenho mais avisos e não estrago o arquivo package.json.


Mais 100. Eu tive que desinstalar localmente e instalar globalmente.
9116 Collin Peters

1

No meu caso, eu vi esse erro dapm! mensagem estranha no meu terminal cygwin quando fiz um 'npm ls'. Eu pensei que isso era algum tipo de configuração corrompida globalmente depois de ter muitos ajustes. Eu aprendo as seguintes observações aqui:

  • 'npm ls' fornece saídas diferentes, dependendo da localização atual da pasta.
  • 'npm ls' tenta detectar a presença de uma pasta 'node_modules' no local atual da pasta e lista esses conteúdos. NÃO os globais!
  • Além disso, se a pasta atual que contém 'node_modules' também tiver um arquivo package.json contendo menos módulos listados aqui, o erro será exibido.

Eu 'rm package.json' e 'npm ls' não mostram mais a mensagem de erro. Por isso, digo que sempre verifique o local atual quanto à presença da pasta 'node_modules' e do arquivo package.json, porque estes são priorizados primeiro na verificação e, se estiverem ausentes, a verificação continua na pasta pai e assim por diante, e se você tiver consertado muitos trechos de código, poderá ter espalhado muitos e muitos arquivos de pasta node_modules e arquivo package.json. Nada está realmente corrompido aqui, diferente das experiências que tivemos ao fazer o desenvolvimento Java J2EE / eclipse IDE ou durante os dias em que precisamos usar o regedit para alterar as configurações no Windows.


1

No meu caso, foi porque o nome do pacote em seu package.jsonarquivo não era o mesmo que o nome package.jsonda dependência listado no módulo dependente. Meu erro, já que é um novo módulo que eu criei, mas difícil de detectar, já que o npm não dá nenhuma pista.

Isso aconteceu ao usar a dependencies: { "my-module": "file:local-modules/mymodule" }sintaxe, com um erro de digitação no nome "my-module".


0

Isso se deve ao fato de seu pacote não estar no seu package.json. Se você adicioná-lo, o problema será resolvido, veja a imagem abaixo:

insira a descrição da imagem aqui

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.