Las rutas de los archivos de Windows Node npm son demasiado largas para instalar paquetes

Situación

Quiero usar gulp y las cadenas de herramientas frontales relacionadas en entornos de desarrollo alojados en Windows. Estoy golpeando una pared tratando de usar los plug-ins de gulp como Browser-Sync, porque el gráfico de la carpeta node_modules hace que las rutas de los archivos de Windows sean demasiado largas para copiar los archivos. Me gustaría un enfoque pragmático para manejar este problema en este momento en Windows, independientemente de lo que la comunidad Node pueda proporcionar o no para mejorar la usabilidad de npm en Windows en el futuro.

2 preguntas

  1. ¿Existe un flujo de trabajo npm para Windows que funcione de la manera que se esperaba? “ejecuta el comando y los archivos se instalan” (ej. comparable a npm en OSX, npm en Linux, ruby ​​gems o incluso nuget) No quiero jugar con un montón de ediciones de archivos manuales, enlaces simbólicos, etc. cada vez que uso npm en Windows.

  2. ¿Hay un flujo de trabajo de Cygwin bien documentado y estable para npm y la ejecución de nodos para solucionar los límites de la ruta del archivo API de Windows?

Detalles de Gory detallados a continuación …

Problema general

  • La ejecución de la instalación de npm desde un símbolo del sistema estándar de Windows falla en las jerarquías de node_modules profundamente anidadas.
  • Según el hilo de github repo de Joyent, este es un problema reconocido sin soluciones aceptables para los desarrolladores en entornos centrados en Windows. ( ¿De verdad? )
  • NT Kernel admite longitudes de ruta de archivo de hasta 32.767 caracteres.
  • El MAXPATH de la API de Windows está limitado a 260 caracteres.
  • La API de Windows maneja las operaciones de archivos para todas las principales conchas de Windows y otras cosas como: Explorer, CMD, Powershell, MYSgit bash, etc. ( ¿Realmente MS? ¿Cuánto tiempo lleva NTFS? )
  • Cygwin admite rutas de archivos largas, pero npm.cmd no funciona de fábrica debido al formato crlf. Probé la transformación DOS2Unix en npm para que funcione con Cygwin, pero parece haber otros problemas con esto.

Mi truco actual

  • Cree una carpeta “n” como área de preparación en la raíz de C: \, porque esto acorta la ruta de mi carpeta.
  • Ejecute npm dentro de la carpeta “n” para instalar módulos para todo lo que necesite.
  • Encienda Cygwin y use cp para copiar la carpeta node_modules en un proyecto de destino.
  • Enjuague y repita cuando cambian las dependencias o cuando necesito activar un nuevo proyecto.

Otras soluciones desagradables

Los enlaces simbólicos se pueden usar para acortar rutas de archivos, pero estos son kludgy hacks. A medida que crezca el ecosistema npm, las cadenas de dependencia anidadas serán demasiado largas y esta solución se volverá inservible.

Agregando TODAS las dependencias al archivo package.json de la carpeta raíz fue mencionado en un hilo que encontré. Aunque este enfoque aplanará la estructura de carpetas y evitará la carga de módulos duplicados, esta solución alternativa no es natural. También elimina la capacidad de uso, la durabilidad y la productividad de npm, ya que tienes que jugar con los archivos y las carpetas después de la instalación, ya sea manualmente o con algunas secuencias de comandos hacky. El enfoque también es vulnerable al mismo destino que el enfoque de los Enlaces Simbólicos eventualmente puede sufrir.

El problema con las carpetas profundamente anidadas en Windows se ha resuelto en su mayoría comenzando con npm versión 3.x

De acuerdo con npm:

.npm @ 3 hace la instalación “máximamente plana” al elevar todo lo que puede al nivel superior node_modules. Esto significa que la anidación solo ocurre en conflictos y, como tal, los árboles nunca deben llegar a ser muy profundos. Como tal, no se debe ejecutar la limitación de longitud de la ruta de Windows.

Acabo de instalar npm 3.1.0 y lo probé en un paquete que estaba lanzando lo temido. The specified path, file name, or both are too long error The specified path, file name, or both are too long .

El problema desapareció

Puede obtener las últimas comstackciones npm desde aquí: lanzamientos npm

Windows 8.1 y 10 tienen una opción para boost el límite de ruta de Win32:

  • Abra el Editor de políticas de grupo (presione Windows + R y escriba gpedit.msc y presione Enter )
  • Navegue al siguiente directorio: Política de equipo local \ Configuración del equipo \ Plantillas administrativas \ Sistema \ Sistema de archivos
  • Haga doble clic en la opción Habilitar rutas largas de Win32 y habilítelo.

enter image description here

Esta es una solución alternativa.

Hay algunos módulos de nodo que aplanan sus dependencias por usted.
Los enlaces están aquí:

  • npm-flatten
  • npm-dedupe

Lo que estos módulos están haciendo también se puede hacer manualmente. Esta es la única solución real que existe a partir de ahora, es decir, tener todos sus módulos en un solo nivel, requiriéndose el uno al otro, en lugar de tener todas las copias privadas de sus dependencias anidadas profundamente.

Allan –

Del problema de Github que vinculó,

npm agregará dedupe-at-install-time de manera predeterminada. Esto es mucho más factible que el cambio en el sistema de módulos de Node, pero todavía no es exactamente trivial e implica una gran reelaboración de algunos patrones arraigados desde hace tiempo.

Esto es (finalmente) actualmente en las obras en npm, que se conoce con el nombre de instalación de multi-stage-install , y está dirigido a npm@3 . npm desarrollo de npm Forrest Norvell va a pasar algún tiempo corriendo en Windows en el nuevo año, así que cree problemas relacionados con Windows en el npm problemas npm < https://github.com/npm/npm/issues >

Tengo el mismo problema. El aplanamiento de las dependencias no es una solución completa, ya que podría estar utilizando módulos que dependen de diferentes versiones del mismo módulo dependiente. Descubrí que el módulo run-run dejó de funcionar después del aplanamiento (en relación con las suposiciones del módulo sobre los directorios bin / .bin, sospecho). ¡Drat!

Hay mucha discusión sobre el problema, pero no hay solución a la vista: https://github.com/joyent/node/issues/6960

https://github.com/npm/npm/issues/3697

Una solución alternativa que me funciona es agregar manualmente dependencias que mi proyecto no necesita explícitamente.

Si desea identificar qué paquetes le están dando problemas, encontré PathLengthChecker bastante útil. Simplemente extraiga el EXE y ejecute la GUI o la aplicación de línea de comandos. La otra forma en que descubrí el problema es intentar construir en Visual Studio, pero falla sin decirle qué nombre de directorio es demasiado largo.

Aquí hay un ejemplo de línea de comando de mi solución:

 mkdir c:\reallylongdirectorywillbreakinwindows cd c:\reallylongdirectorywillbreakinwindows npm init npm install --save-dev grunt-bower-task PathLengthChecker.exe RootDirectory="C:\reallylongdirectorywillbreakinwindows" MinLength=260 

Regresé:

261: C: \ reallylongdirectorywillbreakinwindows \ node_modules \ grunt-bower-task \ node_modules \ bower \ node_modules \ update-notifier \ node_modules \ latest-version \ node_modules \ package-json \ no de_modules \ registry-url \ node_modules \ npmconf \ node_modules \ config-chain \ readme.markdown

[recorte – hubo 12 de ellos]

De acuerdo con el comando npm ls :

 └─┬ grunt-bower-task@0.4.0 ├── async@0.1.22 ├─┬ bower@1.3.12 │ ├─┬ update-notifier@0.2.0 │ │ ├─┬ latest-version@0.2.0 │ │ │ └─┬ package-json@0.2.0 │ │ │ └─┬ registry-url@0.1.1 │ │ │ └─┬ npmconf@2.1.1 │ │ │ ├─┬ once@1.3.1 │ │ │ │ └── wrappy@1.0.1 

Vámonos con npmconf: es el contenedor de todos los archivos de extensión que están causando problemas. Necesitamos npmconf 2.1.1.

 npm install --save-dev npmconf@2.1.1 (now delete the node_modules directory - you may have to use Windows Explorer if you can't do it with rmdir /s) npm install PathLengthChecker.exe RootDirectory="C:\reallylongdirectorywillbreakinwindows" MinLength=260 

Sin resultados: ¡todos los archivos están dentro de los límites!

La advertencia obvia aquí es que solo funciona una vez por paquete: las dependencias de diferentes versiones del mismo módulo no pueden instalarse en el nivel raíz node_modules porque el nodo no tiene en cuenta las versiones en la estructura del directorio.

Esta solución alternativa no es perfecta, pero soluciona mis principales objectives de tener trabajo de nodos en Windows, y como la resolución está en package.json, la solución alternativa funciona para otros desarrolladores y servidores de comstackción sin ningún problema manual o global.

Si está bien con la instalación global, esto podría ser una solución alternativa:

Puede ajustar la ruta en la que npm está instalando los módulos globales a algo muy corto (generalmente es c: \ users \ {username} \ AppData \ Roaming \ npm \ npm_modules) que ya tiene muchos caracteres.

Para ajustarlo, consulte aquí: ¿ Cambiar el directorio de instalación global predeterminado para los módulos node.js en Windows?

Si lo ajusta, por ejemplo, c: \ n \ en algunos casos, podría resolver el problema.

Esto es lo que finalmente me arregló …

Después de instalar gulp y recibir errores, ejecuta … gulp

Cuando vea que un paquete falla, instálelo manualmente con --no-bin-link .

 sudo npm install {package} --no-bin-link 

Donde {paquete} es el paquete que está teniendo problemas.

Después de todo esto, recibí un mensaje de error en el complemento ‘gulp-notify’: no ​​encontrado: notify-send.

Esto se debió a un problema de complemento con Vagrant. Puedes desactivar las notificaciones …

 export DISABLE_NOTIFIER=true; 

O instala el complemento con Vagrant .

La mejor de las suertes. Pasé mucho tiempo en esto, incluso después de seguir muchas recomendaciones de la gente.

Brandon

En windows:

  1. Usando su explorador de Windows, navegue a su carpeta compartida vagabunda (estoy usando scotchbox por cierto) eg C:\scotchbox/public/gulpProject
  2. En la barra de direcciones de la carpeta, escriba cmd y presione Entrar
  3. Haga su instalación de gulp npm install

npm install --no-bin-link . Tendrás un node_modules aplanados completo