Nvm-windows: Soporte .nvmrc

Creado en 8 ene. 2016  ·  18Comentarios  ·  Fuente: coreybutler/nvm-windows

Permite al proyecto especificar la versión a utilizar.
Ver el uso de nvm

o tal vez analizar la versión disponible del armario de los motores package.json

enhancement request wontfix

Comentario más útil

La compatibilidad con .nvmrc es un aspecto bastante importante del uso de NVM con un sistema CI. No vinculo la sugerencia de package.json, especialmente porque rompe la compatibilidad con nvm, pero ¿se aceptaría una solicitud de extracción con soporte para .nvmrc?

Todos 18 comentarios

No creo que esta sea una ruta que quiera seguir. La razón principal es que requeriría una piratería muy fea para recrear / imitar el binario del nodo. Por ejemplo, llamar a node index.js significa que el node.exe pirateado / falsificado necesitaría analizar primero el archivo package.json (si es que existe) para determinar la versión y luego ejecutar el archivo node.exe real

Algunos otros proyectos similares han intentado usar archivos .bat para lograr esto. Este enfoque es frágil y va en contra del objetivo principal de la arquitectura .

Tampoco creo que la demanda sea generalizada para esto.

La compatibilidad con .nvmrc es un aspecto bastante importante del uso de NVM con un sistema CI. No vinculo la sugerencia de package.json, especialmente porque rompe la compatibilidad con nvm, pero ¿se aceptaría una solicitud de extracción con soporte para .nvmrc?

@ gruber76 - Probablemente no acepte un PR sobre esto.

.nvmrc , package.json ... ambos requieren el mismo truco desagradable.

@coreybutler No estoy seguro de entender su razón de ser para no querer apoyar esto. ¿Tener esta función no sería simplemente una alternativa para buscar en el archivo .nvmrc cada vez que se invoca nvm sin especificar un número de versión? Por lo tanto, ¿de qué hacks desagradables estás hablando?

El truco desagradable: reescribir enlaces simbólicos para Windows.

NVM para Windows funciona cambiando el destino del enlace simbólico al directorio de instalación del nodo físico deseado. Este es un cambio de todo el sistema.

Supongamos que inicia un script especificando la versión 0.12.0 en un archivo .nvmrc , luego inicia un segundo script sin .nvmrc . El enlace simbólico apuntaría a v0.12.0 (desde la primera instanciación). Si el segundo script requiere algo más (como v4.2.6) sin .nvmrc , fallará. Esto introduce inestabilidad en el entorno cuando se utilizan enlaces simbólicos porque no existe un verdadero aislamiento del proceso.

La única forma de aislar verdaderamente una versión por proceso es hacer que nvm.exe redirija a la versión que solicita el script en lugar de permitir que el sistema operativo lo haga. Realmente no quiero recrear algo que el sistema operativo ya hace por nosotros.

Si la gente realmente quiere utilizar un enfoque por proceso / proyecto, una solución más apropiada es aislar el entorno de ejecución. Personalmente, uso Docker para eso.

Perdóname por mi ignorancia, aquí. Mi caso de uso principal es desarrollar aplicaciones web / de nodos usando bower / grunt / gulp, etc. con varios equipos. Para mí, es extremadamente raro que tenga varias versiones ejecutándose con cinco minutos de diferencia. Para este caso de uso, el archivo .nvmrc es cómo mis equipos especifican qué nodo debería estar haciendo.

Tengo problemas para ver en la situación que describe (secuencia de comandos A versus secuencia de comandos B) cómo admitir .nvmrc sería más problemático que tener la secuencia de comandos A (o un usuario de la secuencia de comandos A) llamando a nvm para configurar la versión y luego olvidarse de configurar antes de ejecutar el script B. Pero supongo que hay algunos casos de uso comunes para nvm que son mucho más difíciles que el mío. Posiblemente, por ejemplo, si mis servidores de CI tuvieran una carga más pesada.

Tengo una solución alternativa de hackey para ofrecer a cualquier otra persona que la necesite. Lo siguiente en un script bat previo a la ejecución:

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

¿Por qué no poner el comando nvm para configurar la versión requerida en un script npm?

Steve Lee
Enviado desde mi dispositivo móvil Disculpe los errores de escritura
El 3 de marzo de 2016 a las 16:50, "gruber76" [email protected] escribió:

Perdóname por mi ignorancia, aquí. Mi caso de uso principal se está desarrollando
aplicaciones de nodo / web que utilizan bower / grunt / gulp, etc. con varios equipos. Para
para mí, es extremadamente raro que tenga varias versiones ejecutándose en
cinco minutos el uno del otro. Para este caso de uso, el archivo .nvmrc es cómo mi
los equipos especifican qué debe hacer el nodo.

Tengo problemas para ver en la situación que describe (guión A versus
script B) cómo soportar .nvmrc sería más problemático que tener
script A (o un usuario del script A) llamando a nvm para configurar la versión y luego
olvidando configurarlo antes de ejecutar el script B. Pero supongo que hay
algunos casos de uso comunes para nvm que son mucho más difíciles que el mío.
Posiblemente, por ejemplo, si mis servidores de CI tuvieran una carga más pesada.

Tengo una solución alternativa de hackey para ofrecer a cualquier otra persona que la necesite. los
siguiendo en un script bat previo a la ejecución:

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

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/coreybutler/nvm-windows/issues/128#issuecomment -191852401
.

Sería realmente útil admitir el archivo .nvmrc . Tenemos muchos proyectos y no todos ejecutan la misma versión de node. El archivo .nvmrc está en la raíz de cada repositorio para garantizar que se esté utilizando la versión correcta del nodo para un proyecto determinado.

Como nota al margen, también es un poco molesto que nvm install deba ir seguido de nvm use . Tengo curiosidad por saber el razonamiento detrás de requerir el segundo paso después de una instalación. Puedo ver cómo la instalación y el uso son cosas diferentes, pero me pregunto si alguna vez habrá un caso de uso en el que alguien descargaría e instalaría, pero no usaría.

Nuestra solución para esto es que tenemos un archivo llamado install-node.js que vive en la raíz de cada proyecto. Siempre que cambiamos a un proyecto, ejecutamos node install-node desde la línea de comando. El contenido del archivo install-node.js es el siguiente:

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: la separación entre install y use fue principalmente para la configuración de entornos masivos. A menudo instalaré varias versiones de nodo antes de cambiar entre ellas. Sin embargo; parece perfectamente razonable tener una bandera, como nvm install -u 5.9.1 para instalar y usar automáticamente ... o usar automáticamente la versión y tener una bandera para _no_ usarla. Definitivamente consideraré agregar esto.

Para todos: si realmente necesita cambiar por proyecto, considere poner nvm use x.x.x && node index.js en la sección del script de inicio npm de su package.json. Una práctica recomendada común es usar siempre npm start para iniciar una aplicación de nodo.

Para todos: si realmente necesita cambiar por proyecto, considere colocar nvm use xxx && node index.js en la sección de script de inicio de npm de su package.json. Una práctica recomendada común es usar siempre npm start para iniciar una aplicación de nodo.

En realidad, eso podría ser demasiado tarde en el caso de que se utilicen scripts de npm _build_ durante la instalación que dependan de la versión de node / npm. O otras herramientas, como grunt, etc., se ejecutan explícitamente. Podrían fallar durante la instalación con la versión incorrecta de node / npm. o usar la versión incorrecta causando otros problemas, por cierto, estoy asumiendo la otra mejor práctica de tener _todo_ instalado localmente (es decir, no -g) para que las dependencias de la versión nunca sean un problema.

Por lo tanto, es una buena práctica usar npm install para configurar todo. Luego puede agregar un paso de preinstalación para usar nvm use. por ejemplo, agregar

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

Eso debería estar bien incluso si la versión original de npm se ejecutará en el proceso principal. El paso de instalación lanzará un nuevo shell, por lo que todas las acciones deberían recoger el nuevo nodo y npm.

Es posible que incluso desee agregar un paso previo al inicio de las instalaciones.

@SteveALee : sí, tienes razón, mi sugerencia anterior no funcionaría. Sería demasiado tarde en el proceso para lanzarlo de manera confiable.

@coreybutler Al final fui por esto

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

¿Quizás una opción nvm use -i x.x.x sería buena? Es decir, ¿instalar si aún no está allí?

Me gustaría sugerir implementar una parte de esto al menos:

En Linux / Mac, en una carpeta con un archivo .nvmrc presente, puedo ejecutar nvm use sin especificar una versión concreta, y la versión instalada que coincide con el contenido de .nvmrc obtiene activado. Si el archivo dice 8 , entonces se instala la última versión instalada del Nodo 8.

Combino esto en mis sistemas con un script que sobrecarga cd para poder cd en un directorio y se activa la versión correcta del nodo, con este script en .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'; }

Esto también podría funcionar fácilmente en Windows, si nvm respetara estos archivos.

Un .nvmrc no se implementará de forma predeterminada. Sin embargo; la hoja de ruta tiene un plan para el soporte de hooks (https://github.com/coreybutler/nvm-windows/issues/190). Se podría usar un script pre-use para ajustar la versión de acuerdo con cualquier archivo que deseen (incluido package.json, .nvmrc o cualquier otra cosa que elija).

Dado que este problema parece estar casi muerto, tengo un script de Powershell de solución alternativa que debería imitar la funcionalidad de "nvm use" y "nvm install" si el archivo .nvmrc contiene una versión de nodo de un solo dígito.

nvm install (Get-Content .nvmrc) funcionaría bien, sin embargo nvm use (Get-Content .nvmrc) no funcionará (porque cuando se pasa una versión de un solo dígito para instalar, se instala la revisión más reciente de esa versión de nodo, pero nvm use con un solo dígito le agrega '.0.0' en lugar de obtener el más reciente.

@coreybutler Si actualizaste el comando "use" en nvm.go para usar el mismo código que install , esta corrección no sería necesaria (es decir):
if len(version) == 1 { version = findLatestSubVersion(version) } else { version = cleanVersion(version) }

El siguiente script usará "nvm list available" y filtrará la lista para la versión de LTS más alta que coincida con la versión del archivo .nvmrc y luego 'nvm use'. Si no está instalado, 'nvm lo instala y luego' nvm lo usa '.
((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())

Solo quiero solicitar el soporte de nvm use para leer desde un archivo .nvmrc. Realmente haría que mi experiencia de desarrollo de nodos entre Mac y Windows fuera perfecta.

¿Está cerrado porque se arregló o no se va a cambiar?

¿Existe otra versión compatible con Windows de nvm que use la misma API que las versiones * nix?

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

leiamac picture leiamac  ·  4Comentarios

thany picture thany  ·  4Comentarios

webspecialist picture webspecialist  ·  5Comentarios

Deilan picture Deilan  ·  4Comentarios

David263 picture David263  ·  3Comentarios