[] Mi instalación de Windows no está en inglés.
[x] lea el archivo README para estar al tanto de errores de npm y problemas de antivirus.
[x] se aseguró de que esta no sea una pregunta sobre cómo usar NVM para Windows, ya que gitter se usa para preguntas y comentarios.
[] settings.txt
Mismo resultado que nvm use 4.4.4
Salida: node v (64-bit) is not installed.
creó un archivo .nvmrc
con 4.4.4
como la versión del nodo.
vaya a la línea de comando y ejecute nvm use
en la misma carpeta que el archivo.
.nvmrc
nunca ha sido compatible. Esa es una característica específica de nvm, no NVM para Windows.
@coreybutler Soy del Proyecto de Responsabilidad ante .nvmrc
. Estamos empezando a adoptar nvm-windows
para nuestros desarrolladores web voluntarios y me gustaría que reconsideraras el apoyo a .nvmrc
. Este es el sitio en el que usamos .nvmrc.
@ inunotaisho26 - Básicamente, este proyecto se centra en preparar Node como si estuviera instalado de la misma manera que Node se instalaría sin un administrador de versiones. .nvmrc
comienza a meterse en problemas específicos de gestión del entorno, lo que aumenta drásticamente el alcance del proyecto. Veo que la "gestión del entorno" es un problema fundamentalmente diferente al de la "gestión de versiones". Hemos discutido estos casos de uso diferentes en el grupo de trabajo de administración de versiones .
Si bien esta función se solicitó anteriormente, no es algo para lo que tenga suficiente tiempo libre para admitir. Debido a la cantidad de personas que solicitan soluciones generales de gestión del entorno (más allá de solo .nvmrc), estoy experimentando con ideas para una aplicación de gestión del entorno comercial para agilizar estos procesos. Los requisitos de tiempo para respaldar la gran lista de deseos de la comunidad requerirán financiación o patrocinio, por lo que probablemente me apoyaré en la infraestructura que ya he construido para Fenix . El truco: sin ETA.
Dicho esto, consulte la hoja de ruta . La solución "gratuita" que he propuesto es un sistema de gancho, similar a pre-commit
, post-push
, etc. de git. Esto permitiría a los desarrolladores crear sus propios scripts propicios para sus propios entornos únicos. Piense en acciones como post-install
, pre-use
, pre-execute
, etc. Esto permitiría a los usuarios escribir un script de gancho que busque un archivo .nvmrc y cambie la versión sobre la marcha .
@coreybutler Entonces, básicamente, dos enfoques diferentes para instalar múltiples versiones de nodo, ¿verdad?
Algo así como. Hay dos filosofías diferentes, pero se tratan más de _usar_ Node que de instalarlo.
Filosofía 1: Uso nativo (proceso directo)
El nodo en sí no admite .nvmrc
. Simplemente instala su propio ejecutable y npm. Se _utiliza_ ejecutando directamente node.exe.
Filosofía 2: Uso aumentado (subproceso)
.nvmrc
es una convención introducida por el proyecto nvm original. En lugar de llamar a node.exe directamente, usa una corrección. El shim es responsable de configurar un pseudo-entorno antes de pasar comandos al ejecutable del nodo (es decir, el nodo es un subproceso del shim). Aquí es donde se procesa la lógica .nvmrc
. El problema, especialmente en Windows, es que el nodo se ejecuta en el contexto de la corrección, en lugar del contexto del usuario. Esto tiene una serie de efectos / desafíos, como no siempre pasar las credenciales adecuadas al subproceso del nodo (principalmente alrededor de permisos elevados), variables de entorno ligeramente diferentes, no siempre reconocer las particiones del disco duro (como una unidad D: \) y (en en algunos casos) rutas de archivo incorrectas (es decir, __dirname
comporta de forma inesperada), etc. Estos problemas pueden solucionarse, pero se complican cuando se considera el entorno empresarial (implementaciones de Active Directory, escritorios restringidos, unidades SAN, etc.).
La administración general de versiones requiere cierto nivel de corrección para evitar desinstalar / reinstalar el nodo cada vez que necesite cambiar una versión (lo que tomaría una eternidad). NVM4W se alinea con el primer enfoque mediante el uso de enlaces simbólicos para ajustar el _directorio_ de instalación, a diferencia de la opción 2, que ajusta el ejecutable. Como resultado, siempre está ejecutando el ejecutable node.exe directamente, en lugar de ejecutarlo como un subproceso.
Pequeño golpe a este problema. Sólo me encontré con él.
En serio, no puede ser tan difícil. Esto es lo que debe hacer si no se proporciona una versión a nvm use
:
En otras palabras, sin el número de versión especificado, nvm use
es una combinación de nvm install < .nvmrc
y nvm use < .nvmrc
(pseudocomando - en realidad no funcionará en este momento).
No hay mucho más.
Pequeño golpe a este problema. Sólo me encontré con él.
En serio, no puede ser tan difícil. Esto es lo que debe hacer si no se proporciona una versión a
nvm use
:1. Take version from .nvmrc 2. Is this version installed? If not -> install it 3. Is this version currently in use? If not -> use it. 4. Done
En otras palabras, sin el número de versión especificado,
nvm use
es una combinación denvm install < .nvmrc
ynvm use < .nvmrc
(pseudocomando - en realidad no funcionará en este momento).No hay mucho más.
Me alegro de no ser el único que tiene este problema ...
Pensando en volver a Linux para desarrollar: /
@thany @jeromemeichelbeck Siéntase libre de bifurcar el proyecto y agregar esta funcionalidad usted mismo. Publicaré un enlace aquí cuando esté listo.
Comentario más útil
Pequeño golpe a este problema. Sólo me encontré con él.
En serio, no puede ser tan difícil. Esto es lo que debe hacer si no se proporciona una versión a
nvm use
:En otras palabras, sin el número de versión especificado,
nvm use
es una combinación denvm install < .nvmrc
ynvm use < .nvmrc
(pseudocomando - en realidad no funcionará en este momento).No hay mucho más.