Nvm-windows: Carpeta de instalación incorrecta

¿Estoy equivocado o NVM simplemente puso un caché de paquete de nodos de 400 MB en mi perfil de itinerancia?

No, eso es un error en NPM.

La instalación predeterminada apunta al directorio de datos de la aplicación del usuario local, no a la itinerancia. Si bien puede ser mejor tener el ejecutable en una ubicación diferente, todos los archivos de instalación del nodo y npm se consideran datos para NVM (este es un diseño de npm). Nuevamente, estos son valores predeterminados por una razón ... puede cambiarlos si no le gustan.

No tengo idea de dónde está obteniendo 400 MB. ¿Puede proporcionar más detalles sobre su entorno?

En el primer punto, quizás la diferencia es que lo estoy instalando en una computadora adjunta al dominio y tú no. Pero de cualquier manera sigue estando mal. AppData es para configuraciones de usuario, no ejecutables.

En cuanto al segundo punto, es el propio Nodo quien comete ese error. Les presentaré un error por separado.

Esto no es necesariamente "incorrecto", pero si está teniendo efectos adversos, me complace considerar su caso de uso. No tuve la misma experiencia con una computadora adjunta a un dominio, por lo que, nuevamente, los detalles del entorno me ayudarían a comprender su caso de uso específico.

Por ejemplo, si sé qué buscar, puedo hacer que la próxima versión del instalador sea compatible con el dominio. En otras palabras, la ubicación de instalación predeterminada podría ser más inteligente.

Aquí están las recomendaciones de referencia:

• Los programas van en %ProgramFiles% , que normalmente es C:\Program Files .
• En una máquina de 64 bits, los programas x86 antiguos van en %ProgramFiles(x86)% , que suele ser C:\Program Files (x86) .
• Los datos del programa de toda la máquina, como los cachés de paquetes, van en %ProgramData% , que normalmente es C:\ProgramData
• Las configuraciones de usuario que pueden moverse de forma segura de una máquina a otra van en %APPDATA%
• Las configuraciones de usuario que son locales para una máquina determinada (por ejemplo, las que contienen rutas de instalación) van en %LOCALAPPDATA% .

No es raro que los ejecutables estén en appdata. Las aplicaciones instaladas usando clickonce do it, que es un instalador hecho por microsoft. Chrome lo hace. Muchas cosas lo hacen.

@aljones Una de las principales razones es la siguiente : instalar programas en el perfil de usuario puede ser conveniente, pero definitivamente tiene consecuencias de seguridad en el sentido de que cualquier proceso puede modificar cosas como le plazca. Tenga en cuenta que ClickOnce se instala en el perfil de usuario, pero también garantiza que los ensamblados tengan menos privilegios en el sistema.

Si bien hay casos de uso general para instalar aplicaciones por usuario sin necesidad de privilegios administrativos, es un comportamiento predeterminado muy pobre y Chrome sienta un mal precedente aquí, en mi humilde opinión.

Creo que mi experiencia más reciente es relevante para la discusión: recientemente tuve un cambio de estación de trabajo. Las rutas para node_packages en mi perfil de itinerancia eran tan profundas, que la restauración del perfil de itinerancia que mi máquina intentó hacer fallaba cada vez hasta que eliminé la carpeta node_packages. Estos errores aparecieron en los registros de eventos de Windows. Después de hacer eso, mi nueva estación de trabajo finalmente pudo sincronizar mi perfil de itinerancia.

Estoy de acuerdo en que la instalación en roaming causa problemas cuando trabajas en empresas que hacen una copia de seguridad de tu perfil para usarlo en sus redes. Por ejemplo, mi computadora tarda 30 minutos en apagarse y 30 minutos en reiniciarse; todo debido a los módulos npm. Desafortunadamente, AFAIK, este es un problema con la propia NPM.

Como seguimiento de esto:

En general, es importante tener en cuenta que cualquier administrador de versiones solo administra programas. Reitero un comentario anterior .... en el sentido de NVM, el programa instalado (nodo) _es_ los datos. La forma en que lo use (es decir, los módulos npm) puede contribuir a la huella.

@ sam3k tiene razón en que la huella está definitivamente relacionada con la forma en que se diseñó npm, y realmente no hay mucho que NVM _debe_ hacer para esto, ni hay mucho que npm en sí mismo pueda hacer por esto. Todo se reduce a saber lo que está instalando, y un administrador de paquetes de cualquier tipo hace que sea fácil dar esto por sentado. Mucha gente no presta atención a la huella de los módulos, que es un problema de calidad de código / entorno inherente al mundo del código abierto. En resumen, depende de la comunidad resolver este problema mediante prácticas de codificación disciplinadas (una tarea que no es trivial). Soy uno de los muchos que han abogado por esto (consulte npm necesita un entrenador personal . Punto: la administración de npm va más allá de la premisa básica de administrar qué versión de nodo está ejecutando.

@aljones y @ygra tienen buenos puntos. No estoy en desacuerdo con ellos, pero quiero recordarles a todos que los privilegios administrativos son una necesidad para que los enlaces simbólicos funcionen. Este es el principio fundamental de cómo funciona NVM para Windows.

@cokobware tiene lo que creo que es un problema común en los entornos empresariales. La conclusión es que npm no fue diseñado para una fácil portabilidad a escala. Una instancia de node + npm ya es bastante pesada, y mucho menos agregar varias versiones. Independientemente de cómo se muevan los datos / archivos de una estación de trabajo a otra, hay tantos que llevará un tiempo. Las opciones son usar perfiles móviles de Windows, comprimir todo y transferir manualmente, o volver a descargar desde un registro npm. No importa cómo lo gires, sincronizar una estación de trabajo solo tomará tiempo para colocar todos los bits en el lugar correcto.

El futuro de NVM para Windows (a partir de ahora) probablemente seguirá centrado en el cambio de versión de nodo. Incluso puedo cambiar el nombre del proyecto para reflejar eso. Continuará proporcionando un instalador con valores predeterminados comunes, pero aún dependerá de la organización / desarrollador anular estos valores predeterminados de una manera apropiada para su organización. Veo la administración de versiones de nodos como un problema claramente diferente de la administración de huellas npm, aunque estoy experimentando formas en las que NVM4W puede proporcionar enlaces para una mejor administración de npm.

Siga la sugerencia de @Grauenwolf y estas referencias: guía de implementación , CSIDL y variables de entorno

• El enlace simbólico% USERPROFILE% AppData a% PROGRAMFILES% o% PROGRAMFILES (X86)% es una mala idea. Problema en el usuario múltiple (problema de propiedad. Otro usuario no puede acceder al enlace).
• Se supone que el programa nvm está almacenado en% PROGRAMFILES% o% PROGRAMFILES (X86)%.
• Se supone que el repositorio de nodejses está almacenado en% PROGRAMDATA% ya que el alcance son todos los usuarios.
• Se supone que el enlace activo de nodejs debe almacenarse en% LOCALAPPDATA% ya que el alcance es por usuario.

NVM no se puede instalar en% PROGRAMFILES% debido a otros errores. Si lo coloca en una carpeta que tiene un espacio en su nombre, el comando de instalación falla.