I percorsi dei file di Windows del nodo npm sono troppo lunghi per installare i pacchetti

Situazione

Voglio usare gulp e le relative catene di strumenti front-end negli ambienti di sviluppo ospitati da Windows. Sto colpendo un muro cercando di utilizzare plug-in gulp come Browser-Sync, perché il grafico della cartella node_modules si apre a ventaglio rendendo i percorsi dei file di Windows troppo lunghi per copiare i file. Vorrei un approccio pragmatico per gestire questo problema in questo momento su Windows, indipendentemente da ciò che la comunità di Node può o non può fornire per migliorare l'usabilità di npm su Windows in futuro.

2 domande

1. Esiste un flusso di lavoro npm per Windows che funziona nel modo previsto? "esegui il comando e installa i file" (ad es. paragonabile a npm su OSX, npm su Linux, ruby ​​gems o anche nuget) Non voglio giocherellare con un mucchio di modifiche manuali ai file, collegamenti simbolici, ecc. npm su Windows.

2. Esiste un flusso di lavoro Cygwin ben documentato e stabile per l'esecuzione di npm e nodi per aggirare i limiti del percorso del file API di Windows?

Dettagli cruenti elencati di seguito ...

Problema generale

• L'esecuzione dell'installazione di npm da un prompt dei comandi standard di Windows non riesce su gerarchie node_modules profondamente nidificate.
• Secondo il thread del repository github di Joyent, questo è un problema riconosciuto senza soluzioni alternative appetibili per gli sviluppatori in ambienti incentrati su Windows. ( Davvero? )
• Il kernel NT supporta lunghezze di percorso file fino a 32.767 caratteri.
• MAXPATH dell'API di Windows è limitato a 260 caratteri.
• L'API di Windows gestisce le operazioni sui file per tutte le principali shell di Windows e quant'altro, inclusi: Explorer, CMD, Powershell, MYSgit bash, ecc. ( MS davvero? Da quanto tempo esiste NTFS? )
• Cygwin supporta percorsi di file lunghi, ma npm.cmd non funziona immediatamente a causa della formattazione crlf. Ho provato la trasformazione DOS2Unix su npm per farlo funzionare con Cygwin, ma sembrano esserci altri problemi con questo.

Il mio attuale hack

• Creare una cartella "n" come area di gestione temporanea nella directory principale di C: \, perché questo accorcia il percorso della mia cartella.
• Esegui npm nella cartella "n" per installare i moduli per qualsiasi cosa mi serva.
• Avvia Cygwin e usa cp per copiare la cartella node_modules in un progetto di destinazione.
• Risciacquare e ripetere quando le dipendenze cambiano o quando ho bisogno di avviare un nuovo progetto.

Altre soluzioni sgradevoli

I collegamenti simbolici possono essere utilizzati per abbreviare i percorsi dei file, ma si tratta di hack kludgy. Man mano che l'ecosistema npm cresce, le catene di dipendenze annidate diventeranno troppo lunghe e questa soluzione alternativa diventerà inutilizzabile.

L'aggiunta di TUTTE le dipendenze al file package.json della cartella principale è stata menzionata in un thread in cui mi sono imbattuto. Sebbene questo approccio appiattirà la struttura delle cartelle e impedirà il caricamento di moduli duplicati, questa soluzione alternativa sembra innaturale. Uccide anche l'usabilità, la durata e la produttività di npm, perché devi armeggiare con file e cartelle post-installazione manualmente o con alcuni script hacky. L'approccio è anche vulnerabile alla stessa sorte che l'approccio Link simbolici potrebbe eventualmente subire.

Il problema con le cartelle profondamente nidificate su Windows è stato per lo più risolto a partire dalla versione npm 3.x.

Secondo npm:

.npm @ 3 rende l'installazione "massimamente piatta" sollevando tutto ciò che può ai node_modules di livello superiore. Ciò significa che la nidificazione avviene solo in caso di conflitto e, come tale, gli alberi non dovrebbero mai diventare molto profondi. Pertanto, la limitazione della lunghezza del percorso di Windows non dovrebbe essere eseguita.

Ho appena installato npm 3.1.0e l' ho provato su un pacchetto che generava il temuto The specified path, file name, or both are too longerrore.

Il problema è andato via.

Puoi ottenere le ultime build di npm da qui: versioni di npm

Windows 8.1 e 10 hanno un'opzione per aumentare il limite del percorso Win32:

• Apri l'Editor criteri di gruppo (premi Windows+, Rdigita gpedit.msce premi Enter)
• Vai alla seguente directory: Local Computer Policy\Computer Configuration\Administrative Templates\System\Filesystem
• Fare doppio clic sull'opzione Abilita percorsi lunghi Win32 e abilitarla.

Questa è una soluzione per aggirare il problema.

Ci sono alcuni moduli del nodo che appiattiscono le tue dipendenze.
I link sono qui:

• npm-flatten
• npm-dedupe

Ciò che questi moduli stanno facendo può essere fatto anche manualmente. Questa è l'unica vera soluzione al momento esistente, ovvero avere tutti i moduli a un unico livello, che si richiedono a vicenda, invece di avere tutti copie private delle loro dipendenze annidate profondamente.

Allan -

Dal problema di GitHub che hai collegato,

npm aggiungerà la deduplicazione al momento dell'installazione per impostazione predefinita. Questo è significativamente più fattibile rispetto alla modifica del sistema del modulo di Node, ma non è ancora esattamente banale e comporta un sacco di rielaborazione di alcuni schemi a lungo radicati.

Questo è (finalmente) attualmente in lavorazione a npm, va sotto il nome multi-stage-installed è mirato npm@3. npmIl responsabile dello sviluppo Forrest Norvell trascorrerà un po 'di tempo in esecuzione su Windows nel nuovo anno, quindi crea problemi relativi a Windows sul npmtracciatore di problemi < https://github.com/npm/npm/issues >

Ho lo stesso problema. L'appiattimento delle dipendenze non è una soluzione completa, poiché potresti utilizzare moduli che dipendono da versioni diverse dello stesso modulo dipendente. Ho scoperto che il modulo gulp-run ha smesso di funzionare dopo l'appiattimento (in relazione alle ipotesi del modulo sulle directory bin / .bin, sospetto). Drat!

Ci sono molte discussioni sul problema, ma nessuna soluzione in vista: https://github.com/joyent/node/issues/6960

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

Una soluzione alternativa che funziona per me è aggiungere manualmente le dipendenze di cui il mio progetto non necessita esplicitamente.

Se vuoi identificare quali pacchetti ti stanno dando problemi, ho trovato PathLengthChecker abbastanza utile. Basta estrarre l'EXE ed eseguire la GUI o l'app della riga di comando. L'altro modo in cui ho scoperto il problema è provare a compilare in Visual Studio, ma non riesce senza dirti quale nome di directory è troppo lungo.

Ecco un esempio della riga di comando della mia soluzione alternativa:

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

Sono tornato:

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 \ npmconfules \ npmconfules config-chain \ readme.markdown

[snip - c'erano 12 di loro]

Secondo il 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

Andiamo con npmconf: è il contenitore di tutti i file di lunghezza eccessiva che causano problemi. Abbiamo bisogno di 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

Nessun risultato: tutti i file rientrano nei limiti!

L'ovvia avvertenza qui è che funziona solo una volta per pacchetto: le dipendenze su diverse versioni dello stesso modulo non possono essere installate a livello root node_modules perché node non tiene conto delle versioni nella struttura della directory.

Questa soluzione alternativa non è perfetta, ma risolve i miei obiettivi principali di far funzionare i nodi su Windows e, poiché la risoluzione è giusta in package.json, la soluzione alternativa funziona per altri sviluppatori e crea server senza complicazioni manuali o globali.

Se sei d'accordo con l'installazione globale, questa potrebbe essere una soluzione:

Puoi regolare il percorso in cui npm sta installando i moduli globali su qualcosa di molto breve (di solito è :) c:\users\\{username}\AppData\Roaming\npm\npm_modulesche richiede già molti caratteri.

Per modificarlo, vedere qui: Modificare la directory di installazione globale predefinita per i moduli node.js in Windows?

Se lo modifichi, ad esempio, c:\n\in alcuni casi potrebbe risolvere il problema.

Questo è ciò che alla fine lo ha risolto per me ...

Dopo aver installato gulp e ricevuto errori, esegui ... gulp

Quando vedi un pacchetto che non funziona, installalo manualmente con --no-bin-link.

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

Dove {pacchetto} è il pacchetto che sta avendo problemi.

Dopo tutto questo ho ricevuto un errore nel messaggio "gulp-notify" del plugin: non trovato: notify-send.

Ciò era dovuto a un problema di plug-in con Vagrant. Puoi disattivare le notifiche ..

export DISABLE_NOTIFIER=true;

Oppure installa il plugin con Vagrant .

In bocca al lupo .. Ci ho passato molto tempo, anche dopo aver seguito i consigli di molte persone.

Brandon

In Windows:

1. Usando il tuo Windows Explorer, vai alla tua cartella condivisa vagabonda (sto usando scotchbox tra l'altro) es C:\scotchbox/public/gulpProject
2. Nella barra degli indirizzi della cartella, digita cmde premiEnter
3. Fai la tua installazione di gulp npm install

npm install --no-bin-link. Avrai un intero appiattito node_modules