webpack --watch non sta compilando i file modificati

Ho provato a correre webpack --watche dopo aver modificato i miei file JS, non si attiva una ricompilazione automatica.

Ho provato a reinstallare webpackutilizzando npm uninstallma non funziona ancora.

Qualche idea?

Cordiali saluti: sembra che OS X possa avere una cartella danneggiata e non più inviare fsevents(che watchpack/ chokidar/ Finder usa) per se stessa e per le cartelle figlio. Non posso essere sicuro che sia quello che ti è successo, ma è stato molto frustrante per me e per un collega.

Siamo stati in grado di rinominare la cartella principale danneggiata e quindi guardare gli eventi immediatamente come previsto. Vedi questo post del blog per maggiori informazioni: http://feedback.livereload.com/knowledgebase/articles/86239-os-x-fsevents-bug-may-prevent-monitoring-of-certai

Le soluzioni consigliate dal collegamento precedente sono:

• riavviare il computer
• controllando il disco e riparando le autorizzazioni tramite Utility Disco
• aggiungendo la cartella all'elenco della privacy di Spotlight (l'elenco delle cartelle da non indicizzare) e quindi rimuovendola, forzando di fatto una reindicizzazione
• rinominare la cartella e quindi eventualmente rinominarla nuovamente
• ricreando la cartella e spostando nuovamente i vecchi contenuti al suo interno

I primi due non hanno funzionato per noi, non hanno provato il suggerimento di Spotlight e la ricreazione non si è rivelata necessaria.

Siamo stati in grado di trovare la cartella del problema principale aprendo Finder e creando file in ciascuna cartella principale successiva fino a quando non ne viene visualizzato uno immediatamente (poiché anche Finder verrà eliminato da questo bug). La principale cartella che non si aggiorna è il colpevole. L'abbiamo appena mvfatto e mvriportato al suo nome originale, e poi l'osservatore ha funzionato.

Non ho idea di cosa causi la corruzione, ma sono solo contento di avere una soluzione.

Se il tuo codice non viene ricompilato, prova ad aumentare il numero di watcher (in Ubuntu):

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Fonte: https://webpack.github.io/docs/troubleshooting.html

L'aggiunta del seguente codice al file di configurazione del mio webpack ha risolto il problema per me, spero che questo aiuti. Non dimenticare di ignorare la tua cartella node_modules, poiché ciò ucciderebbe le prestazioni per HMR (Hot Module Replacement):

watchOptions: {
  poll: true,
  ignored: /node_modules/
}

Ho avuto questo problema lavorando con WebStorm.

Disattivando Impostazioni -> Impostazioni di sistema -> "scrittura sicura" è stato risolto per me.

Ho trovato il consiglio per farlo in: Risoluzione dei problemi di WebPack

Solo per aggiungere alle possibili soluzioni: avevo la cartella del mio progetto all'interno di una cartella Dropbox, spostandola fuori ha risolto il problema per me. (OS X)

La distinzione tra maiuscole e minuscole era il mio problema. Le mie chiamate in codice a require () avevano tutti i nomi di percorso in minuscolo MA le directory in realtà avevano una lettera maiuscola. Ho rinominato tutte le mie directory in minuscolo e la visualizzazione del webpack ha funzionato immediatamente.

Un problema è che se i nomi dei percorsi non sono assoluti, accadranno cose del genere. Mi ero accidentalmente impostato resolve.rootsu ./invece di __dirnamee questo mi ha fatto perdere molto tempo a eliminare e ricreare file come i ragazzi sopra di me.

Se la modifica di fs.inotify.max_user_watches come sottolineato da César continua a non funzionare, prova a utilizzare il polling invece degli osservatori nativi creando il tuo script come mostrato nei documenti o eseguendo webpack con le --watch --watch-pollopzioni.

Nota che se esegui webpack all'interno di una macchina virtuale (Vagrant / Virtualbox) e modifichi i tuoi file sulla piattaforma host, gli aggiornamenti dei file nella cartella condivisa potrebbero non attivare inotify su Ubuntu. Ciò farà sì che le modifiche non vengano rilevate da webpack.

vedi: biglietto Virtualbox # 10660

Nel mio caso, la modifica e il salvataggio del file su de guest (in vi) ha attivato webpack. Modificandolo sull'host (in PhpStorm, Notepad o qualsiasi altra applicazione) NON si attivava il webpack qualunque cosa io facessi.

L'ho risolto usando vagrant-fsnotify .

Lavora per me a Laravel Homestead

--watch --watch-poll

Aggiornamenti: l'eliminazione dell'intera directory e la nuova clonazione di git dal repository risolve il mio problema.

Se stai usando Vim dovresti provare a impostare backupcopy su yes piuttosto che sull'auto predefinita. Altrimenti Vim a volte rinominerà il file originale e ne creerà uno nuovo, che rovinerà il webpack watch:

https://github.com/webpack/webpack/issues/781

Basta aggiungerlo alle impostazioni di vim se questo è il caso:

imposta backupcopy = yes

Ho riscontrato lo stesso problema su un file .vue. Quando il server è stato riavviato, tutto ha funzionato bene, ma al salvataggio successivo non è stato più ricompilato. Il problema riguardava il percorso del file di importazione con una lettera maiuscola. È molto difficile capire questo problema perché tutto funziona al riavvio del server. Controlla il caso dei tuoi percorsi.

Non si stava ricompilando per me, ma poi mi sono reso conto / ricordato che webpack guarda il grafico delle dipendenze e non solo una cartella (o file). Di sicuro, i file che stavo cambiando non facevano ancora parte di quel grafico.

Per me, la creazione di cartelle e file in VS Code era il problema. Per risolvere il problema, ho ri-clonato il mio repository e questa volta ho creato nuove cartelle e file tramite la riga di comando anziché il codice. Penso che il codice stia corrompendo i file per qualche motivo. Ho visto l'applicazione appena aggiornata quindi forse è un nuovo bug.

Ho avuto un problema simile, né il webpack né il rollup in modalità orologio hanno rilevato le modifiche apportate. Ho scoperto che era fondamentalmente colpa mia mentre stavo cambiando modulo (file .tsx) che non era ancora importato da nessuna parte nell'applicazione (ad esempio App.ts che è il punto di ingresso) e mi aspettavo che gli strumenti di compilazione segnalassero errori. fatto lì.

Il modo in cui ho risolto il problema è stato trovare un errore di maiuscole in un percorso di importazione. La cartella nel file system aveva la prima lettera minuscola, il percorso di importazione era maiuscolo. Tutto è stato compilato bene, quindi questo era solo un problema con l'orologio webpack.

Inoltre ha avuto questo problema all'interno di una VM VirtualBox (5.2.18) Ubuntu (18.04) utilizzando Vagrant (2.1.15) con sincronizzazione rsync. All'improvviso, la prima build funziona alla grande, ma Webpack non prende in considerazione le modifiche successive, anche con fs.inotify.max_user_watches=524288set. Anche l'aggiunta poll: truenella configurazione di Webpack non ha aiutato.

vagrant-notify-forwarderHa funzionato solo (vagrant-fsnotify no, per qualche motivo), ma poi la ricostruzione è avvenuta troppo velocemente dopo aver salvato il file sull'host e suppongo che rsync non abbia avuto abbastanza tempo per completare il suo compito (forse a causa della quantità di directory sincronizzate all'interno del mio Vagrantfile?).

Finalmente ho fatto di nuovo funzionare l'orologio aumentando anche la aggregateTimeoutconfigurazione del mio Webpack:

module.exports = {
  watch: true,
  watchOptions: {
    aggregateTimeout: 10000
  },
  ...
}

Se questa soluzione funziona per te, prova ad abbassare nuovamente questo valore, altrimenti dovrai attendere 10 secondi fino al riavvio della build ogni volta che premi Salva. Il valore predefinito è 300 ms .

Ho lo stesso problema. E noto che non si sta compilando perché la mia cartella contiene alcuni caratteri (*). E l'utilizzo del vecchio plug-in watcher sembra risolvere il problema. Aggiungi questa riga al file di configurazione del tuo webpack.

plugins: [
    new webpack.OldWatchingPlugin()
  ]

Per me l'eliminazione node_modulese l'esecuzione di npm install o di nuovo filato per installare tutti i pacchetti ha risolto il problema

Qual è stata la causa nel mio caso:

Sembra che il valore di: max_user_watches nel /proc/sys/fs/inotify/max_user_watches webpack stia influenzando

Per controllare il tuo valore effettivo

$cat /proc/sys/fs/inotify/max_user_watches
16384

16384 era nel mio caso e ancora non era abbastanza.

Ho provato diversi tipi di soluzioni come:

$ echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p

Ma sembra che anche se avessi cambiato il valore, quando avessi riavviato il mio PC sarebbe tornato a quello predefinito 16384.

SOLUZIONE se hai un sistema operativo Linux (il mio caso, ho Manjaro):

Crea il file:

sudo nano /etc/sysctl.d/90-override.conf

E popolalo con:

fs.inotify.max_user_watches=200000

Sembra che 200000 siano sufficienti per me.

Dopo aver creato il file e aggiunto il valore, riavvia semplicemente il PC e dovresti essere a posto.

Una semplice soluzione su MacOS è la seguente:

Apri due finestre di terminale nella stessa directory in cui risiede il tuo progetto.

Nella prima finestra del terminale eseguire: webpack --watch

Nella seconda finestra del terminale eseguire: webpack-dev-server

Ho provato molte soluzioni possibili e questa sembra essere la più affidabile

Possibile soluzione: modifica del contesto nella directory dell'app.

Avevo tutti i miei file di configurazione del pacchetto web in una sottocartella:

components/
webpack/
 development.js
app.js

In webpack/development.js, set ha context: path.join(__dirname, '../')risolto il mio problema.

Dopo aver provato una manciata di strategie per risolvere questo problema, ho finito per arrendermi, ma poi mentre risolvo un altro problema ho provato di nuovo e all'improvviso la --watchbandiera ha finalmente funzionato.

Ad essere sincero non so cosa lo abbia fatto funzionare nello specifico, ma dopo aver eseguito i seguenti passaggi ha appena iniziato a funzionare:

1. Install most recent gcc version
$ sudo port install gcc48
$ sudo port select --set gcc mp-gcc48

2. Install most recent clang version
$ sudo port install clang-3.6
$ sudo port select --set clang mp-clang-3.6

3. Export variables holding the patch to C and C++ compiler
$ export CC=/opt/local/bin/clang
$ export CXX=/opt/local/bin/clang++

Potrebbe essere successo che durante l'installazione di questi pacchetti qualche dipendenza aggiungesse semplicemente il pezzo mancante del puzzle, chissà ...

Spero che questo aiuti chiunque abbia difficoltà a farlo funzionare.

Aggiungo un'altra risposta perché credo che questa sia la soluzione migliore finora. Lo sto usando tutti i giorni ed è fantastico! Basta installare questa libreria:

https://github.com/gajus/write-file-webpack-plugin

Descrizione: forza il programma webpack-dev-server a scrivere i file bundle nel file system.

Come installare :

npm install write-file-webpack-plugin --save-dev

Prova a cambiare --watchin-d --watch

ha funzionato per me

Se ciò è accaduto all'improvviso nel tuo progetto, questo potrebbe risolvere il problema.

Forse in qualche modo i file che stavano monitorando le modifiche al tuo progetto che webpack cerca sono stati danneggiati. Puoi crearli di nuovo semplicemente seguendo semplici passaggi.

1. esci dal tuo progetto dir. ($: cd ..)
2. sposta il tuo progetto in una directory diversa ($: mv {projectName} {newName})
3. vai nella nuova directory ($: cd {newName})
4. avvia il server e controlla se si ricarica ad ogni modifica di file (dovrebbe funzionare nella maggior parte dei casi, perché ora webpack crea nuovi file per controllare le modifiche)
5. esci dalla directory ($: cd ..)
6. riportalo al suo nome originale ($: mv {newName} {projectNam}) Questo ha funzionato per me ............

Mi sono imbattuto in questa domanda quando stavo riscontrando un problema simile: sembrava che webpack non fosse riassemblato, anche durante l'esecuzione di webpack --config.

Ho anche eliminato bundle.js e la pagina web veniva ancora visualizzata come prima delle mie modifiche.

Per quelli di voi che hanno lo stesso problema, ho finalmente fatto l'opzione 'svuota cache e ricarica difficile' in Chrome (fai clic con il pulsante destro del mouse sul pulsante di ricarica con devtools aperti) e questo ha funzionato

Ho riscontrato lo stesso problema, provato molte cose, finalmente Chrome Cancella dati di navigazione su Mac ha funzionato per me.

Questi moduli sono stati installati:

"browser-sync": "^ 2.26.7",

"browser-sync-webpack-plugin": "^ 2.2.2",

"webpack": "^ 4.41.2",

"webpack-cli": "^ 3.3.9"

Il problema era nella distinzione tra i file .js e .ts. Perché ?

Nella compilazione del progetto, Visual Studio compila i file dattiloscritti in .js e .js.map. Questo non è assolutamente necessario, perché webpack gestisce anche i file dattiloscritti (con un fantastico caricatore di caratteri). Quando si modificano i file componet .tsx in Visual Studio Code o con l' opzione compileOnSave disabilitata in tsconfig.json, il file ts modificato non viene ricompilato e il mio webpack stava elaborando un file .js non effettivo.

La soluzione era disabilitare la compilazione dei file dattiloscritti in Visual Studio durante la compilazione del progetto. Inserisci

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

in PropertyGroup del tuo .csproj.