web-dev-qa-db-fra.com

Node Les chemins de fichiers Windows 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 me heurte à un mur en essayant d'utiliser des plug-ins gulp comme Browser-Sync, car le graphe du dossier node_modules se vide, rendant les chemins de fichiers Windows trop longs pour copier les fichiers. Je souhaite une approche pragmatique pour traiter ce problème dès maintenant sous Windows, indépendamment de ce que la communauté Node peut fournir ou non 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? "lance la commande et installe les fichiers" (par exemple, comparable à npm sous OSX, npm sous Linux, Ruby gems ou même nuget) Je ne veux pas me mêler de modifications manuelles des fichiers , liens symboliques, etc. chaque fois que j'utilise npm sous Windows.

  2. Existe-t-il un flux de travaux Cygwin stable et bien documenté pour l'exécution de npm et de nœuds permettant de contourner les limites de chemin d'accès aux fichiers de l'API Windows?

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

Problème général

  • L'exécution de npm install à partir d'une commande Windows standard L'invite échoue sur les hiérarchies de nœuds_modules profondément imbriquées.
  • Le fil repith de github de Per Joyent, il s'agit d'un problème bien conn sans solutions de contournement acceptables pour les développeurs dans les environnements Windows. ( vraiment? )
  • Le noyau NT prend en charge des longueurs de chemin de fichier allant jusqu'à 32 767 caractères.
  • MAXPATH de l'API Windows est limité à 260 caractères.
  • L'API Windows gère les opérations sur les fichiers pour tous les principaux shells Windows et autres, y compris: Explorer, CMD, Powershell, MYSgit bash, etc. ( MS? Depuis combien de temps NTFS existe-t-il? )
  • Cygwin prend en charge les chemins de fichiers longs, mais npm.cmd ne fonctionne pas à l’origine en raison du formatage crlf. J'ai essayé la transformation DOS2Unix sur NPM pour que cela fonctionne avec Cygwin, mais il semble y avoir d'autres problèmes avec cela.

Mon piratage actuel

  • Créez un dossier "n" en tant que zone de stockage intermédiaire à la racine de C: \, car cela raccourcit le chemin d'accès à mon dossier.
  • Exécutez npm dans le dossier "n" pour installer les modules nécessaires.
  • Lancez Cygwin et utilisez cp pour copier le dossier node_modules dans un projet de destination.
  • Rincez et recommencez lorsque les dépendances changent ou lorsque je dois lancer un nouveau projet.

Autres solutions de contournement peu agréables

Des liens symboliques peuvent être utilisés pour raccourcir les chemins d'accès aux fichiers, mais ce sont des piratages aléatoires. À mesure que l'écosystème npm se développe, les chaînes de dépendance imbriquées deviennent trop longues et cette solution de contournement devient inutilisable.

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

windowsnode.jsnpmfilepath
87
Allan McLemore

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

Selon npm:

.npm @ 3 rend l’installation "à plat au maximum" en soulevant tout ce qu’elle peut sur les node_modules de niveau supérieur. Cela signifie que la nidification n'a lieu que lors de conflits et qu'en tant que telle, les arbres ne doivent jamais être très profonds. En tant que tel, la limitation de la longueur du chemin Windows ne doit pas être utilisée.

Je viens d'installer npm 3.1.0 et l’essayé sur un paquet qui jetait le redouté The specified path, file name, or both are too long Erreur.

Le problème est parti.

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

55
biofractal

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+R et tapez gpedit.msc et appuyez sur Enter)
  • Accédez au répertoire suivant: Stratégie de l'ordinateur local\Configuration ordinateur\Modèles d'administration\Système\Système de fichiers
  • Double-cliquez sur Activez l'option des chemins longs Win32 et activez-la.

enter image description here

20
Marcelo Mason

Ceci est une solution de contournement.

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

Ce que font ces modules peut aussi être fait manuellement. C’est la seule solution réelle qui existe à ce jour, c’est-à-dire que tous vos modules se trouvent à un même niveau, s’exigeant mutuellement, au lieu d’avoir des copies privées de leurs dépendances profondément imbriquées.

12
Amol M Kulkarni

J'ai le même problème. L'aplatissement des dépendances n'est pas une solution complète, car vous utiliserez 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 de module concernant les répertoires bin/.bin, je suppose). Drat!

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

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 voulez identifier les paquets qui vous posent des problèmes, j’ai trouvé PathLengthChecker très utile. Il suffit d'extraire le fichier EXE et d'exécuter 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 construire dans Visual Studio, mais cela échoue sans vous dire qui Le nom de répertoire est trop long.

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

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:\reallongdirectorywillbreakinwindows\node_modules\grunt-bower-tâche\node_modules\bower\node_modules\update-notifier\node_modules\latest-version\node_modules\package-json\no de_modules\registry-url\node_modules config-chain\readme.markdown

[Snip - ils étaient 12]

Selon la commande npm ls :

└─┬ [email protected]
  ├── [email protected]
  ├─┬ [email protected]
  │ ├─┬ [email protected]
  │ │ ├─┬ [email protected]
  │ │ │ └─┬ [email protected]
  │ │ │   └─┬ [email protected]
  │ │ │     └─┬ [email protected]
  │ │ │       ├─┬ [email protected]
  │ │ │       │ └── [email protected]

Allons-y avec npmconf - c'est le conteneur pour tous les fichiers trop longs qui posent problème. Nous avons besoin de npmconf 2.1.1.

npm install --save-dev [email protected]
(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!

L'avertissement évident ici est qu'il ne fonctionne qu'une seule fois par paquet: les dépendances sur différentes versions du même module ne peuvent pas être installées au niveau du noeud racine_modules car le noeud ne tient pas compte des versions de la structure de répertoires.

Cette solution de contournement n'est pas parfaite, mais elle résout mes objectifs principaux, qui consiste à faire fonctionner les nœuds sous Windows. Comme la résolution est conforme à package.json, la solution de contournement fonctionne pour les autres développeurs et permet de créer des serveurs sans fioritures ni manœuvres générales ni manuelles.

3
Stefan Mohr

Allan -

À partir du numéro de github que vous avez lié,

npm ajoutera par défaut dedupe-at-install-time. Ceci est bien plus réalisable que le changement de système de modules de Node, mais ce n’est pas encore tout à fait trivial, et implique de retravailler en profondeur certains modèles enracinés depuis longtemps.

C'est (enfin) actuellement en préparation chez npm, sous le nom de multi-stage-install, et est ciblé pour npm@3. npm responsable du développement Forrest Norvell va passer du temps à s'exécuter sous Windows au cours de la prochaine année. Créez donc des problèmes liés à Windows sur le suivi des problèmes npm < https://github.com/npm/npm/issues >

3
Sam Mikes

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 sur quelque chose de très court (généralement c:\utilisateurs\{nom d'utilisateur}\AppData\Roaming\npm\npm_modules) qui 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 sous Windows?

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

2
gwildu

Dans les fenêtres:

  1. À l'aide de votre explorateur Windows, accédez à votre dossier partagé vagrant (j'utilise scotchbox d'ailleurs), par exemple C:\scotchbox/public/gulpProject
  2. Dans la barre d'adresse du dossier, tapez cmd et appuyez sur Enter
  3. Faites votre installation gulp npm install
0
Justis Matotoka

C'est ce qui a finalement été résolu pour moi ...

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

Quand vous voyez un paquet é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: introuvable: 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

0
user3310182

npm install --no-bin-link. Vous aurez un entier aplatinode_modules

0
kenberkeley