Nvm-windows: Suporte .nvmrc

Não acho que esse seja um caminho que eu queira seguir. O principal motivo é que seria necessário um hacking muito desagradável para recriar / imitar o binário do nó. Por exemplo, chamar node index.js significa que o hackeado / falsificado node.exe precisaria primeiro analisar o arquivo package.json (se ele existir) para determinar a versão e, em seguida, executar o node.exe real

Alguns outros projetos semelhantes tentaram usar .bat arquivos para fazer isso. Essa abordagem é frágil e vai contra o objetivo principal da arquitetura .

Eu também não acho que a demanda seja muito grande para isso.

O suporte .nvmrc é um aspecto bastante importante do uso de NVM com um sistema CI. Não vinculo a sugestão de package.json, especialmente porque quebra a compatibilidade com nvm, mas uma solicitação pull com suporte para .nvmrc seria aceita?

@ gruber76 - Provavelmente não aceitarei um PR sobre isso.

.nvmrc , package.json ... ambos requerem o mesmo hack desagradável.

@coreybutler Não tenho certeza se entendo sua razão para não querer apoiar isso. Ter esse recurso simplesmente não voltaria a examinar o arquivo .nvmrc sempre que o nvm fosse invocado sem especificar um número de versão? Portanto, de que hacks desagradáveis ​​você está falando?

O hack desagradável: reescrever links simbólicos para Windows.

O NVM para Windows funciona alterando o destino do link simbólico para o diretório de instalação do nó físico desejado. Esta é uma mudança em todo o sistema.

Digamos que você inicie um script especificando a versão 0.12.0 em um arquivo .nvmrc e, em seguida, inicie um segundo script sem .nvmrc . O link simbólico apontaria para v0.12.0 (desde a primeira instanciação). Se o segundo script exigir algo diferente (como v4.2.6) sem .nvmrc , ele falhará. Isso introduz a instabilidade do ambiente ao usar links simbólicos porque não há um verdadeiro isolamento do processo.

A única maneira de realmente isolar uma versão por processo é fazer com que nvm.exe redirecione para a versão que o script está solicitando, em vez de permitir que o sistema operacional faça isso. Eu realmente não quero recriar algo que o sistema operacional já faz por nós.

Se as pessoas realmente desejam usar uma abordagem por processo / projeto, uma solução mais apropriada é isolar o ambiente de execução. Pessoalmente, eu uso o Docker para isso.

Perdoe-me por minha ignorância, aqui. Meu principal caso de uso é desenvolver aplicativos de nó / web usando bower / grunt / gulp, etc. com várias equipes. Para mim, é extremamente raro ter várias versões rodando cinco minutos uma da outra. Para este caso de uso, o arquivo .nvmrc é como minhas equipes especificam o que o nó deve estar fazendo.

Estou tendo problemas para ver na situação que você descreve (script A versus script B) como o suporte .nvmrc seria mais problemático do que ter o script A (ou um usuário do script A) chamando nvm para definir a versão e depois se esquecendo de definir antes de executar o script B. Mas estou supondo que haja alguns casos de uso comuns para nvm que são muito mais complexos do que os meus. Possivelmente, por exemplo, se meus servidores de CI tiveram uma carga mais pesada.

Eu tenho uma solução alternativa de hackey para oferecer a qualquer pessoa que precise. O seguinte em um script bat pré-execução:

set /p nodev=<.nvmrc
nvm install %nodev%
nvm use %nodev%

Por que não colocar o comando nvm para definir a versão necessária em um script npm?

Steve Lee
Enviado do meu dispositivo móvel Desculpe erros de digitação
Em 3 de março de 2016 16:50, "gruber76" [email protected] escreveu:

Perdoe-me por minha ignorância, aqui. Meu principal caso de uso é o desenvolvimento
nodo / aplicações web usando bower / grunt / gulp, etc. com várias equipes. Para
para mim, é extremamente raro ter várias versões em execução dentro
cinco minutos um do outro. Para este caso de uso, o arquivo .nvmrc é como meu
as equipes especificam o que o nó deve estar fazendo.

Estou tendo problemas para ver a situação que você descreve (script A versus
script B) como apoiar .nvmrc seria mais problemático do que ter
script A (ou um usuário do script A) chamando nvm para definir a versão e então
esquecendo-se de defini-lo antes de executar o script B. Mas acho que há
alguns casos de uso comuns para nvm que são muito mais complexos do que o meu.
Possivelmente, por exemplo, se meus servidores de CI tiveram uma carga mais pesada.

Eu tenho uma solução alternativa de hackey para oferecer a qualquer pessoa que precise. o
seguindo em um script bat pré-execução:

definir / p nodev = <. nvmrc
nvm install% nodev%
nvm use% nodev%

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/coreybutler/nvm-windows/issues/128#issuecomment -191852401
.

Apoiar o arquivo .nvmrc seria muito útil. Temos muitos projetos e nem todos executam a mesma versão do nó. O arquivo .nvmrc está na raiz de cada repositório para garantir que a versão correta do nó esteja sendo usada para um determinado projeto.

Como observação lateral, também é meio irritante que nvm install deva ser seguido por nvm use . Estou curioso para saber o raciocínio por trás da exigência da segunda etapa após a instalação. Eu posso ver como instalar e usar são coisas diferentes, mas eu me pergunto se existe um caso de uso em que alguém baixaria e instalaria, mas não usaria.

Nossa solução para isso é que temos um arquivo chamado install-node.js que reside na raiz de cada projeto. Sempre que mudamos para um projeto, executamos node install-node partir da linha de comando. O conteúdo do arquivo install-node.js é o seguinte:

var childProcess = require('child_process')
var fs = require('fs')

var nodeVersion = fs.readFileSync('.nvmrc', 'utf8').trim()

var command = "nvm install " + nodeVersion + " && nvm use " + nodeVersion
console.log('executing command: ' + command)
childProcess.exec(command, function(error, stdout, stderr) {
  if (stdout) console.log(stdout.toString())
  if (stderr) console.error(stderr.toString())
  if (error) console.error(error)
})

@ josh-egan-ps - A separação entre install e use foi principalmente para configuração de ambiente em massa. Freqüentemente, instalo várias versões do nó antes de alternar entre elas. Contudo; parece perfeitamente razoável ter um sinalizador, como nvm install -u 5.9.1 para instalar e usar automaticamente ... ou usar automaticamente a versão e ter um sinalizador para _não_ usá-lo. Definitivamente vou considerar adicionar isso.

Para todos - se você realmente precisar alternar por projeto, considere colocar nvm use x.x.x && node index.js na seção de script de início npm de seu package.json. Uma prática recomendada comum é sempre usar npm start para iniciar um aplicativo de nó.

Para todos - se você realmente precisar alternar por projeto, considere colocar nvm use xxx && node index.js na seção npm start script de seu package.json. Uma prática recomendada comum é sempre usar npm start para iniciar um aplicativo de nó.

Na verdade, isso pode ser tarde demais no caso de qualquer script npm _build_ usado durante a instalação que dependa da versão do nó / npm. Ou outras ferramentas, como grunt, etc., são executadas com precisão. Eles podem falhar durante a instalação com a versão errada do nó / npm. ou usar a versão errada causando outros problemas, BTW, estou assumindo a outra prática recomendada de ter _tudo_ instalado localmente (ou seja, não -g) para que as dependências de versão nunca sejam um problema.

Portanto, é uma boa prática usar npm install para configurar tudo. Você pode então adicionar uma etapa de pré-instalação para usar o nvm. por exemplo, adicionar

    "preinstall": "nvm use x.x.x",

Isso deve estar OK, mesmo se a versão original do npm for executada no processo pai. A etapa de instalação iniciará um novo shell, portanto, todas as ações devem selecionar o novo nó e o npm.

Você pode até querer adicionar uma etapa de pré-início em vez de instalações.

@SteveALee - sim, você está certo, minha sugestão anterior não funcionaria. Seria muito tarde no processo para um lançamento confiável.

@coreybutler No final eu fui para isso

"preinstall":"nvm use 4.4.1 || echo nvm not found: check node version && pause",

Talvez uma opção nvm use -i x.x.x fosse boa? Ou seja, instale se ainda não estiver lá?

Eu gostaria de sugerir implementar pelo menos uma parte disso:

No Linux / Mac, em uma pasta com um arquivo .nvmrc presente, posso executar nvm use sem especificar uma versão concreta, e a versão instalada que corresponde ao conteúdo de .nvmrc obtém ativado. Se o arquivo disser 8 , a versão instalada mais recente do Nó 8 será instalada.

Eu combino isso em meus sistemas com um script que sobrecarrega cd para que eu possa cd em um diretório e a versão correta do nó seja ativada, com este script em .bashrc :

# Support .nvmrc
load-nvmrc() {
  if [[ -f .nvmrc && -r .nvmrc ]]; then
    nvm use
  elif [[ $(nvm version) != $(nvm version default)  ]]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
# Override `cd` to auto-load correct version of Node on enterting directory.
cd() { builtin cd "$@"; 'load-nvmrc'; }

Isso poderia funcionar facilmente no Windows também, se nvm respeitasse esses arquivos.

Um .nvmrc não será implementado por padrão. Contudo; o roteiro tem um plano para suporte de gancho (https://github.com/coreybutler/nvm-windows/issues/190). Um script pre-use pode ser usado para ajustar a versão de acordo com qualquer arquivo que eles quiserem (incluindo package.json, .nvmrc ou qualquer outro que você escolher).

Como esse problema parece estar quase morto, eu tenho um script Powershell de solução alternativa que deve imitar a funcionalidade de "nvm use" e "nvm install" se o arquivo .nvmrc contiver uma versão de nó de um único dígito.

nvm install (Get-Content .nvmrc) funcionaria bem, entretanto nvm use (Get-Content .nvmrc) não funcionaria (porque quando uma versão de um dígito é passada para instalar, ele instala a revisão mais recente dessa versão do nó, mas nvm use com um único dígito anexa '.0.0' a ele em vez de obter o mais recente.

@coreybutler Se você atualizou o comando "use" em nvm.go para usar o mesmo código que install , isso tornaria esta correção desnecessária (ou seja):
if len(version) == 1 { version = findLatestSubVersion(version) } else { version = cleanVersion(version) }

O script a seguir usará "lista nvm disponível" e filtrará a lista para a versão LTS mais alta que corresponda à versão do arquivo .nvmrc e então 'nvm usará'. Se não estiver instalado, é 'nvm install's it e' nvm use '.
((nvm use (nvm list available | Where-Object -FilterScript { $_ -like ('* ' + (Get-Content .nvmrc)) + '.*'})[0].split('|')[2].trim()) -like '*not installed*') -and (nvm install (nvm list available | Where-Object -FilterScript { $_ -like ('* ' + (Get-Content .nvmrc) + '.*') })[0].split('|')[2]) -and (nvm use (nvm list available | Where-Object -FilterScript { $_ -like ('* ' + (Get-Content .nvmrc) + '.*') })[0].split('|')[2].trim())

Só quero solicitar o suporte do nvm usar para ler um arquivo .nvmrc. Realmente faria minha experiência de desenvolvimento de nó entre Mac e Windows ser perfeita.

Está fechado porque foi corrigido ou não vai ser alterado?

Existe outra versão compatível com Windows de nvm que usa a mesma API que as versões * nix?