Nvm-windows: nvm não funciona em situações de 32/64 bits para Windows 7

Criado em 18 jul. 2016  ·  10Comentários  ·  Fonte: coreybutler/nvm-windows

Meu ambiente

  • [X] Windows 7 ou inferior (não é realmente compatível devido ao EOL)
  • [] Windows 8
  • [] Windows 8.1
  • [] Windows 10
  • [] Windows 10 IoT Core
  • [] Windows Server 2012
  • [] Windows Server 2012 R2
  • [] Windows Server 2016
  • [] Minha instalação do Windows não está em inglês.

    Eu já...

  • [X] leia o README para estar ciente dos problemas do npm e antivírus.

  • [X] revisou o wiki para ter certeza de que meu problema ainda não foi resolvido.
  • [X] verificou que estou usando uma conta com privilégios administrativos.
  • [X] pesquisou os problemas (abertos e fechados) para se certificar de que não era uma duplicata.
  • [X] certificou-se de que esta não seja uma questão sobre como usar o NVM para Windows, já que o gitter é usado para perguntas e comentários.

    Meu problema está relacionado a (marque apenas os que se aplicam):

  • [] settings.txt

  • [] suporte de proxy
  • [X] suporte de 32 ou 64 bits

    Comportamento esperado

Estou executando o Windows 7/64 bits
Instalei (com privilégios de administrador) o NVM para Windows 1.1.1. A partir daí eu usei

nvm install 6.1.0 all
nvm install 6.3.0 all

Então liguei
nvm list
resultando em

C:\Users\kagentes>nvm list
    6.3.0
    6.1.0

Então corri
nvm use 6.3.0 64

e depois
node -v
e esperado obter
v6.3.0

Comportamento Real

Ao correr
node -v
eu recebo

'node' is not recognized as an internal or external command,
operable program or batch file.

Além disso, mesmo depois de definir o comando nvm use, noto que a lista não parece confirmar se o comando "use" está funcionando. Como em:

C:\Users\kagentes>nvm use 6.3.0 64
Now using node v6.3.0 (64-bit)

C:\Users\kagentes>nvm list

    6.3.0
    6.1.0

A partir das capturas de tela na página https://github.com/coreybutler/nvm-windows , acredito que o comando nvm list deve retornar algo assim abaixo (mas NÃO estou entendendo isso )

C:\Users\kagentes>nvm list

*   6.3.0 (In Use)
    6.1.0

Não tem o asterisco ou o indicador "em uso".

Possivelmente, isso também ajudará a diagnosticar o problema, mas quando eu executo o comando nvm arch , obtenho os seguintes resultados estranhos, independentemente do que configurei em nvm use :

C:\Users\kagentes>nvm arch
System Default: 64-bit.
Currently Configured: -bit.

Etapas para reproduzir o problema:

As etapas para reproduzir já são fornecidas na seção de comportamento esperado acima. Já tentei recomendações possíveis em outros problemas, como o problema # 146, bem como reiniciar o shell, reiniciar o computador e garantir que tudo fosse feito com privilégios de administrador. Antes de começar tudo isso, desinstalei versões anteriores do Node que estavam no computador. (então instalei o nvm-windows e seguiu suas instruções).

help wanted

Comentários muito úteis

@kgentes - assumirei que antes do nvm você instalou a versão de 64 bits do nó e instalou o nvm usando os padrões.

Após desinstalar o nó, certifique-se de que o diretório onde o nó foi originalmente instalado tenha sido removido e não apenas vazio. Para Windows 7 de 64 bits, o padrão é "C: Program Filesnodejs".

Se o diretório "nodejs" ainda existir, o comando "nvm use" não poderá fazer o link simbólico para a versão do nó sob o controle do nvm.

Eu tive o mesmo problema até que eu exclua manualmente o diretório "nodejs".

espero que ajude

Todos 10 comentários

Desculpe fazer a pergunta óbvia, mas você tentou reiniciar a janela do terminal? No Win7, às vezes ainda engasga na primeira vez que você tenta usar uma versão específica (mklink).

Sim eu fiz. Tentei reiniciar a janela do terminal .. então até a máquina .. nem alterei o resultado.

OK - vou averiguar se tiver tempo. Infelizmente, Win7 não é algo que costumo fazer.

@kgentes - assumirei que antes do nvm você instalou a versão de 64 bits do nó e instalou o nvm usando os padrões.

Após desinstalar o nó, certifique-se de que o diretório onde o nó foi originalmente instalado tenha sido removido e não apenas vazio. Para Windows 7 de 64 bits, o padrão é "C: Program Filesnodejs".

Se o diretório "nodejs" ainda existir, o comando "nvm use" não poderá fazer o link simbólico para a versão do nó sob o controle do nvm.

Eu tive o mesmo problema até que eu exclua manualmente o diretório "nodejs".

espero que ajude

Obrigado @pleverett .. Vou tentar isso em breve .. agradeço o

@pleverett OBRIGADO SENHOR! Isso funcionou como você anunciou! Super gostar! Esse segmento pode ser fechado. Provavelmente deve ser marcada como uma solução (não tenho certeza se isso é algo que pode ser feito, aqui, sou novo neste ecossistema) para futuros usuários do Windows 7 que podem se deparar com este problema. NVM para Windows está funcionando perfeitamente agora, uma vez que removi o diretório "C: Program Filesnodejs" ("C: Program Files (x86) nodejs" para 32 bits) que aparentemente não é removido por padrão do desinstalador. Junto com esse diretório, também removi:
- "C: UsersusernameAppDataRoamingnpm"
- "C: UsersusernameAppDataRoamingnpm-cache"

Embora isso provavelmente não fosse necessário.

De qualquer forma, tudo está funcionando. Obrigado!

@pleverett @coreybutler

outro problema relacionado ---
agora que posso ver e alterar as versões do nó via nvm, me pergunto se devo ver resultados diferentes ao fazer o:

npm config list

No momento, nenhuma das informações, exceto a variável abaixo, muda.
user-agent = "npm/3.10.3 node/v6.3.0 win32 ia32"

todos os outros permanecem os mesmos. E parece que há apenas uma versão dos módulos de nó instalados globalmente.

se eu estiver mudando apenas da versão de 64 bits de 6.3.0 para a versão de 32 bits de 6.3.0, terei as mesmas instalações de módulos de nó globais? ou fará outros distintos? Ou preciso fazer uma alteração de versão para obter um conjunto diferente de módulos de nó instalados globalmente? Idealmente, eu pensaria que ele manteria um contexto único para cada versão de bit (por causa dos módulos de nó nativos como libxml - ??? etc), mas posso ver por que outros podem não gostar que funcione dessa forma.

Ainda estou usando errado? ou este é um bug relacionado?

uma vez que ainda está trabalhando no mesmo tópico, eu queria reabri-lo em vez de criar um novo problema ... [veja o comentário anterior para meu status atualizado]

@kgentes - Lamento ter perdido isso ... provavelmente deve ser um problema diferente.

Se você está apenas mudando de 32-> 64 bits ou vice-versa, o NVM4W usará o mesmo diretório global node_modules . Isso foi feito intencionalmente, principalmente para manter a pegada geral do ambiente do Node a um mínimo. Ter diretórios de instalação separados para 32/64 bits dobrará a pegada da maioria dos usuários ... e a pegada geral é algo em que a maioria dos usuários nem pensa até ficarem sem espaço. Apesar disso, estou inclinado a usar um diretório de instalação individual por versão + arquitetura proc de qualquer maneira. Realmente deve ficar a cargo do usuário, e como você disse, isso quebra alguns pacotes nativos.

Estou encerrando porque o assunto é um pouco diferente. Sinta-se à vontade para abrir uma nova edição, se desejar.

Esta página foi útil?
0 / 5 - 0 avaliações