Nvm-windows: Pasta de instalação incorreta

Estou enganado ou o NVM acabou de colocar um cache de pacote de nó de 400 MB em meu perfil de roaming?

Não, isso é um bug no NPM.

A instalação padrão aponta para o diretório appdata do usuário local, não para o roaming. Embora possa ser melhor ter o executável em um local diferente, todos os arquivos de instalação do nó e npm são considerados dados para NVM (este é um projeto npm). Novamente, esses são padrões por um motivo ... você pode alterá-los se não gostar deles.

Não tenho ideia de onde você está obtendo 400 MB. Você pode fornecer mais detalhes sobre o seu ambiente?

No primeiro ponto, talvez a diferença seja que estou instalando em um computador conectado a um domínio e você não. Mas de qualquer forma, ainda está errado. AppData é para configurações do usuário, não executáveis.

Quanto ao segundo ponto, é o próprio Node cometendo esse erro. Vou registrar um bug com eles separadamente.

Isso não é necessariamente "errado", mas se estiver tendo efeitos adversos, fico feliz em considerar seu caso de uso. Eu não tive a mesma experiência com um computador conectado a um domínio, então, novamente, os detalhes do ambiente me ajudariam a entender seu caso de uso específico.

Por exemplo, se eu souber o que procurar, posso tornar a próxima versão do instalador compatível com o domínio. Em outras palavras, o local de instalação padrão pode ser mais inteligente.

Aqui estão as recomendações básicas:

• Os programas vão em %ProgramFiles% , que geralmente é C:\Program Files .
• Em uma máquina de 64 bits, programas x86 antigos vão em %ProgramFiles(x86)% , que normalmente é C:\Program Files (x86) .
• Os dados do programa de toda a máquina, como caches de pacote, vão em %ProgramData% , que normalmente é C:\ProgramData
• As configurações do usuário que podem se mover com segurança de máquina para máquina vão em %APPDATA%
• As configurações do usuário que são locais para uma determinada máquina (por exemplo, aquelas que contêm caminhos de instalação) vão em %LOCALAPPDATA% .

Não é incomum que executáveis ​​estejam em appdata. Aplicativos instalados usando clickonce fazem isso, que é um instalador feito pela Microsoft. Chrome faz isso. Muitas coisas fazem isso.

@aljones Um dos principais motivos é este - instalar programas no perfil do usuário pode ser conveniente, mas definitivamente tem consequências de segurança, pois qualquer processo pode modificar as coisas como quiser. Observe que o ClickOnce _sobre_ instala no perfil do usuário, mas também garante que os assemblies tenham menos privilégios no sistema.

Embora haja, em geral, casos de uso para instalar aplicativos por usuário sem a necessidade de privilégios administrativos, é um comportamento padrão muito ruim e o Chrome abre um precedente ruim aqui, imho.

Acredito que minha experiência recente seja relevante para a discussão: Recentemente, tive um switch de estação de trabalho. Os caminhos para node_packages em meu perfil de roaming eram tão profundos que a restauração do perfil de roaming que minha máquina tentava fazer falhava todas as vezes até que eu destruísse a pasta node_packages. Esses erros apareceram nos logs de eventos do Windows. Depois de fazer isso, minha nova estação de trabalho pôde finalmente sincronizar meu perfil de roaming.

Concordo que a instalação em roaming causa problemas quando você trabalha em empresas que fazem backup de seu perfil para ser usado em suas redes. Por exemplo, meu computador leva 30 minutos para desligar e 30 minutos para reiniciar; tudo devido aos módulos npm. Infelizmente, AFAIK, esse é um problema do próprio NPM.

Como acompanhamento disso:

Em geral, é importante observar que qualquer gerenciador de versão está apenas gerenciando programas. Reitero um comentário anterior ... no sentido de NVM, o programa instalado (nó) _é_ os dados. Como você o usa (ou seja, módulos npm) pode contribuir para a pegada.

@ sam3k está correto ao dizer que a pegada está definitivamente relacionada a como o npm foi projetado, e não há realmente muito que o NVM _deve_ fazer por isso, nem há muito que o próprio npm possa fazer por isso. Tudo se resume a saber o que você está instalando, e um gerenciador de pacotes de qualquer tipo torna mais fácil considerar isso garantido. Muitas pessoas não prestam atenção à pegada dos módulos, que é um problema de qualidade de código / ambiente inerente ao mundo do código aberto. Resumindo, cabe à comunidade resolver esse problema por meio de práticas de codificação disciplinadas (uma tarefa nada trivial). Eu sou um dos muitos que defendem isso (veja o npm precisa de um personal trainer . Ponto: o gerenciamento do npm vai além da premissa básica de gerenciar qual versão do nó você está executando.

@aljones e @ygra têm pontos positivos. Não discordo deles, mas quero lembrar a todos que os privilégios administrativos são uma necessidade para fazer os links simbólicos funcionarem. Este é o princípio básico de como o NVM para Windows funciona.

@cokobware tem o que acredito ser um problema comum em ambientes corporativos. O resultado final é que o npm não foi projetado para fácil portabilidade em grande escala. Uma instância de node + npm já é bastante pesada, quanto mais adicionar várias versões. Independentemente de como os dados / arquivos se movem de uma estação de trabalho para outra, há tantos deles que vai demorar um pouco. As opções são usar perfis de roaming do Windows, compactar tudo e transferir manualmente ou baixar novamente de um registro npm. Não importa como você gire, sincronizar uma estação de trabalho vai levar algum tempo para colocar todas as partes no lugar certo.

O futuro do NVM para Windows (a partir de agora) provavelmente permanecerá focado na troca de versão de nó. Posso até mudar o nome do projeto para refletir isso. Ele continuará a fornecer um instalador com padrões comuns, mas ainda caberá à organização / desenvolvedor substituir esses padrões de uma maneira apropriada para sua organização. Vejo o gerenciamento de versão de nó como um problema distintamente diferente do gerenciamento de pegada de npm, embora esteja experimentando maneiras nas quais o NVM4W pode fornecer ganchos para um melhor gerenciamento de npm.

Siga a sugestão de @Grauenwolf e estas referências: guia de implantação , CSIDL e variáveis ​​de ambiente

• link simbólico% USERPROFILE% AppData para% PROGRAMFILES% ou% PROGRAMFILES (X86)% é uma má ideia. Problema no usuário múltiplo (problema de propriedade. Outro usuário não consegue acessar o link).
• O programa nvm deve ser armazenado em% PROGRAMFILES% ou% PROGRAMFILES (X86)%.
• O repositório nodejses deve ser armazenado em% PROGRAMDATA%, uma vez que o escopo são todos os usuários.
• O link nodejs ativo deve ser armazenado em% LOCALAPPDATA%, pois o escopo é por usuário.

NVM não pode ser instalado em% PROGRAMFILES% por causa de outros bugs. Se você colocá-lo em uma pasta com um espaço no nome, o comando de instalação falhará.