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

87

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.

windows  node.js  npm  filepath 
— Allan McLemore
source
J'ai presque pensé que j'avais résolu ce problème. J'ai fait travailler Cygwin avec npm en exécutant dos2unix util sur les 2 fichiers suivants: npm.cmd et npm
— Allan McLemore
Les limitations du chemin de l'API Windows rendent npm inutilisable, car certains modules npm utilisent Visual Studio pour créer des fichiers. C'est l'erreur que je reçois lorsque je npm Browser-Sync: C: \ Program Files (x86) \ MSBuild \ Microsoft.Cpp \ v4.0 \ V120 \ Microsoft.CppBuild.targets (301,5): erreur MS B3491: pourrait ne pas écrire de lignes dans le fichier "Release \ obj \ validation \ validation.tlog \ validation.lastbuilds tate". Le chemin, le nom de fichier ou les deux spécifiés sont trop longs. Le nom de fichier complet doit comporter moins de 260 caractères et le nom du répertoire doit comporter moins de 248 caractères.
— Allan McLemore
Je peux avoir une approche "tirant sur la tire" pour obtenir des modules de nœuds chargés avec npm sur Windows. Cela implique quelques cycles des éléments suivants: npm install, npm dedupe, npm shrink et rm -r node_modules. Faire cela à plusieurs reprises semble aplanir les longs chemins de fichiers dans une certaine mesure, mais c'est un peu comme tirer de la tire (par exemple, pas fait tant que vous n'avez pas terminé). Quelqu'un a-t-il codifié cela ou écrit un outil automatisé pour rendre cela plus clé en main?
— Allan McLemore
En parlant de "scripts hacky", j'en ai écrit un que je ne trouve pas TERRIBLEMENT hacky. J'ai créé un outil appelé fenestrate que vous pouvez utiliser pour aplatir par programme la structure de répertoires de vos modules après l'installation. Vous pouvez l'installer en tant que hook de post-installation npm global.
— zetlen
2
@yoneal Pour un usage personnel et pour démarrer rapidement, fenestrate devrait parcourir récursivement votre dossier node_modules, vous ne devriez donc pas avoir besoin de l'exécuter manuellement sur des dépendances profondes. Cependant, ce serait génial de bifurquer ces dépendances - je pense que beaucoup de modules fourchus avec des configurations de fenestration simples enverraient un excellent message aux responsables de npm.
— zetlen

Réponses:

58

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

— biofractale
source
4
J'ai également eu un succès avec la mise à jour npm 3.x sur la machine Windows. Plug sans vergogne: j'ai écrit un article sur npm 3 sur Windows triplet.fi/blog
— ...
21

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.

entrez la description de l'image ici

— Marcelo Mason
source
l'option n'était pas disponible pour moi, et fwiw, j'ai mis à niveau de win 7 pro donc c'est une cause possible
— Evan Morrison
@EvanMorrison "Système de fichiers \ NTFS \ Activer les chemins longs NTFS" a été renommé "Système de fichiers \ Activer les chemins longs Win32" dans les versions ultérieures de win10. J'ai mis à jour la réponse pour référence future.
— Marcelo Mason le
1
toute idée pour Win Server 2012 R2
— sairfan
12

C'est une solution de contournement.

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

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.

— Amol M Kulkarni
source
10
J'ai trouvé que les packages flatten étaient bien documentés et faciles à utiliser.
— StriplingWarrior
3

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 >

— Sam Mikes
source
3

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.

— Stefan Mohr
source
2

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.

— gwildu
source
1

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

— user3310182
source
0

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
— Justis Matotoka
source
1
Évitez de copier-coller la même réponse . Vous devez plutôt marquer comme doublon. De plus, ne jurez pas dans votre message.
— Tunaki le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.