Les chemins d'accès aux fichiers Windows du nœud npm sont trop longs pour installer des packages

Situation

Je souhaite utiliser gulp et les chaînes d'outils frontales associées dans les environnements de développement hébergés par Windows. Je frappe un mur en essayant d'utiliser des plug-ins gulp comme Browser-Sync, car le graphique du dossier node_modules se déploie, ce qui rend les chemins de fichiers Windows trop longs pour copier les fichiers. J'aimerais une approche pragmatique pour gérer ce problème dès maintenant sur Windows, indépendamment de ce que la communauté Node peut ou non fournir pour améliorer la convivialité de npm sur Windows à l'avenir.

2 questions

1. Existe-t-il un flux de travail npm pour Windows qui fonctionne exactement comme prévu? "exécuter la commande et installer les fichiers" (par exemple, comparable à npm sur OSX, npm sur Linux, ruby ​​gems ou même nuget) Je ne veux pas jouer avec un tas de modifications manuelles de fichiers, de liens symboliques, etc. à chaque fois que j'utilise npm sous Windows.

2. Existe-t-il un flux de travail Cygwin stable et bien documenté pour l'exécution de npm et de nœuds afin de contourner les limites de chemin de fichier de l'API Windows?

Détails Gory énumérés ci-dessous ...

Problème général

• L'exécution de l'installation de npm à partir d'une invite de commande Windows standard échoue sur les hiérarchies node_modules profondément imbriquées.
• Selon le fil de repo github de Joyent, il s'agit d'un problème reconnu sans solution de contournement acceptable pour les développeurs dans des environnements Windows. ( Vraiment? )
• NT Kernel prend en charge des longueurs de chemin de fichier jusqu'à 32 767 caractères.
• MAXPATH de l'API Windows est limité à 260 caractères.
• L'API Windows gère les opérations de fichiers pour tous les principaux shells Windows et autres, y compris: Explorer, CMD, Powershell, MYSgit bash, etc. ( MS vraiment? Depuis combien de temps NTFS existe-t-il? )
• Cygwin prend en charge les chemins de fichiers longs, mais npm.cmd ne fonctionne pas directement en raison du formatage crlf. J'ai essayé la transformation DOS2Unix sur npm pour qu'elle fonctionne avec Cygwin, mais il semble y avoir d'autres problèmes avec cela.

Mon hack actuel

• Créez un dossier "n" en tant que zone intermédiaire à la racine de C: \, car cela raccourcit le chemin de mon dossier.
• Exécutez npm dans le dossier "n" pour installer des modules pour tout ce dont j'ai besoin.
• Lancez Cygwin et utilisez cp pour copier le dossier node_modules dans un projet de destination.
• Rincez et répétez lorsque les dépendances changent ou lorsque j'ai besoin de lancer un nouveau projet.

Autres solutions de contournement désagréables

Les liens symboliques peuvent être utilisés pour raccourcir les chemins de fichiers, mais ce sont des hacks kludgy. À mesure que l'écosystème npm se développe, les chaînes de dépendances imbriquées deviendront trop longues et cette solution de contournement deviendra inutilisable.

L'ajout de TOUTES les dépendances au fichier package.json du dossier racine a été mentionné dans un fil de discussion que j'ai rencontré. Bien que cette approche aplatisse la structure des dossiers et empêche le chargement de modules en double, cette solution de contournement ne semble pas naturelle. Cela tue également la convivialité, la durabilité et la productivité de npm, car vous devez manipuler les fichiers et les dossiers après l'installation manuellement ou avec des scripts piratés. L'approche est également vulnérable au même sort que l'approche des liens symboliques peut éventuellement subir.

Le problème des dossiers profondément imbriqués sous Windows a été principalement résolu à partir de la version npm 3.x.

Selon npm:

.npm @ 3 rend l'installation "à plat au maximum" en hissant tout ce qu'il peut au niveau supérieur node_modules. Cela signifie que la nidification ne se produit qu'en cas de conflit et, en tant que tel, les arbres ne devraient jamais être très profonds. En tant que tel, la limitation de longueur de chemin Windows ne doit pas être exécutée.

Je viens d'installer npm 3.1.0et de l'essayer sur un package qui lançait l' The specified path, file name, or both are too longerreur redoutée .

Le problème a disparu.

Vous pouvez obtenir les dernières versions de npm à partir d'ici: versions de npm

Windows 8.1 et 10 ont une option pour augmenter la limite de chemin Win32:

• Ouvrez l'éditeur de stratégie de groupe (appuyez sur Windows+ Ret tapez gpedit.mscet appuyez sur Enter)
• Accédez au répertoire suivant: Local Computer Policy\Computer Configuration\Administrative Templates\System\Filesystem
• Double-cliquez sur l' option Activer les chemins longs Win32 et activez-la.

C'est une solution de contournement.

Il existe des modules de nœuds qui aplatissent vos dépendances pour vous.
Les liens sont ici:

• npm-aplatir
• npm-dedupe

Ce que font ces modules peut également être fait manuellement. C'est la seule vraie solution qui existe pour le moment, c'est-à-dire d'avoir tous vos modules à un seul niveau, se nécessitant les uns les autres, au lieu d'avoir tous des copies privées de leurs dépendances imbriquées profondément.

Allan -

À partir du problème github que vous avez lié,

npm ajoutera par défaut une déduplication lors de l'installation. C'est beaucoup plus faisable que le changement du système de modules de Node, mais ce n'est toujours pas vraiment anodin et implique beaucoup de retouches de certains modèles enracinés depuis longtemps.

Ceci est (enfin) actuellement en cours chez npm, sous le nom multi-stage-install, et est ciblé npm@3. npmLe responsable du développement, Forrest Norvell, va passer du temps à fonctionner sous Windows au cours de la nouvelle année, veuillez donc créer des problèmes liés à Windows sur l' npmoutil de suivi des problèmes < https://github.com/npm/npm/issues >

J'ai le même problème. L'aplatissement des dépendances n'est pas une solution complète, car vous utilisez peut-être des modules qui dépendent de différentes versions du même module dépendant. J'ai découvert que le module gulp-run a cessé de fonctionner après l'aplatissement (lié aux hypothèses du module sur les répertoires bin / .bin, je suppose). Drat!

Il y a beaucoup de discussions sur le problème, mais aucune solution en vue: https://github.com/joyent/node/issues/6960

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

Une solution de contournement qui fonctionne pour moi consiste à ajouter manuellement des dépendances dont mon projet n'a pas explicitement besoin.

Si vous souhaitez identifier les packages qui vous posent des problèmes, j'ai trouvé PathLengthChecker très utile. Extrayez simplement le fichier EXE et exécutez l'interface graphique ou l'application de ligne de commande. L'autre façon dont j'ai découvert le problème est d'essayer de créer dans Visual Studio, mais cela échoue sans vous dire quel nom de répertoire est trop long.

Voici un exemple de ligne de commande de ma solution de contournement:

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

Je suis rentré:

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 \ npmconfodules \ npmconfodules chaîne de configuration \ readme.markdown

[snip - il y en avait 12]

Selon la commande 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

Allons-y avec npmconf - c'est le conteneur pour tous les fichiers de longueur excessive qui causent des problèmes. Nous avons besoin de 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

Aucun résultat - tous les fichiers sont dans les limites!

La mise en garde évidente ici est que cela ne fonctionne qu'une fois par package - les dépendances sur différentes versions du même module ne peuvent pas être installées au niveau racine node_modules car le nœud ne tient pas compte des versions dans la structure de répertoires.

Cette solution de contournement n'est pas parfaite, mais elle résout mes principaux objectifs de faire fonctionner les nœuds sous Windows, et comme la résolution est correcte dans package.json, la solution de contournement fonctionne pour d'autres développeurs et construisez des serveurs sans aucune difficulté manuelle ou globale.

Si vous êtes d'accord pour l'installer globalement, cela pourrait être une solution:

Vous pouvez ajuster le chemin où npm installe les modules globaux à quelque chose de très court (généralement:) c:\users\\{username}\AppData\Roaming\npm\npm_modulesqui prend déjà beaucoup de caractères.

Pour l'ajuster, voir ici: Changer le répertoire d'installation global par défaut pour les modules node.js dans Windows?

Si vous l'ajustez, par exemple, c:\n\dans certains cas, cela peut résoudre le problème.

C'est ce qui a finalement résolu le problème pour moi ...

Après avoir installé gulp et reçu des erreurs, exécutez ... gulp

Lorsque vous voyez un package échouer, installez-le manuellement avec --no-bin-link.

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

Où {package} est le package qui rencontre des problèmes.

Après tout cela, je recevais une erreur dans le plugin 'gulp-notify' Message: not found: notify-send.

Cela était dû à un problème de plugin avec Vagrant. Vous pouvez soit désactiver les notifications.

export DISABLE_NOTIFIER=true;

Ou installez le plugin avec Vagrant .

Bonne chance. J'ai passé beaucoup de temps là-dessus, même après avoir suivi les recommandations de nombreuses personnes.

Brandon

Dans Windows:

1. En utilisant votre explorateur Windows, accédez à votre dossier partagé vagrant (j'utilise scotchbox au fait), par exemple C:\scotchbox/public/gulpProject
2. Dans la barre d'adresse du dossier, tapez cmdet appuyez surEnter
3. Faites votre installation gulp npm install

npm install --no-bin-link. Vous aurez un tout aplati node_modules