webpack --watch nie kompiluje zmienionych plików

Próbowałem uruchomić webpack --watchi po edycji moich plików JS nie powoduje to automatycznej rekompilacji.

Próbowałem ponownie zainstalować webpackza pomocą, npm uninstallale nadal nie działa.

Jakieś pomysły?

FYI: wygląda na to, że OS X może spowodować uszkodzenie folderu i nie wysyłać go fsevents(którego używa watchpack/ chokidar/ Finder) dla siebie i jakichkolwiek folderów podrzędnych. Nie jestem pewien, co ci się przydarzyło, ale było to bardzo frustrujące dla mnie i dla kolegi.

Udało nam się zmienić nazwę uszkodzonego folderu nadrzędnego, a następnie natychmiast obserwować, jak zdarzenia przebiegały zgodnie z oczekiwaniami. Zobacz ten post na blogu, aby uzyskać więcej informacji: http://feedback.livereload.com/knowledgebase/articles/86239-os-x-fsevents-bug-may-prevent-monitoring-of-certai

Zalecane poprawki z powyższego linku to:

• ponowne uruchomienie komputera
• sprawdzanie dysku i naprawianie uprawnień za pomocą Narzędzia dyskowego
• dodanie folderu do listy prywatności Spotlight (lista folderów do nieindeksowania), a następnie usunięcie z niego, skutecznie wymuszając ponowne zindeksowanie
• zmiana nazwy folderu, a następnie prawdopodobnie zmiana nazwy z powrotem
• ponowne utworzenie folderu i przeniesienie z powrotem do niego starej zawartości

Pierwsze dwa nie zadziałały, nie wypróbowały sugestii Spotlight, a odtworzenie nie okazało się konieczne.

Udało nam się znaleźć główny folder problemów, otwierając Findera i tworząc pliki w każdym kolejnym folderze nadrzędnym, aż jeden z nich pojawił się natychmiast (ponieważ Finder również zostanie złapany przez ten błąd). Przyczyną jest folder główny, który nie jest aktualizowany. Po prostu zrobiliśmy mvto i mvprzywróciliśmy jego pierwotną nazwę, a następnie obserwator zadziałał.

Nie mam pojęcia, co powoduje uszkodzenie, ale cieszę się, że mam poprawkę.

Jeśli kod nie jest ponownie kompilowany, spróbuj zwiększyć liczbę obserwatorów (w Ubuntu):

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

Źródło: https://webpack.github.io/docs/troubleshooting.html

Dodanie następującego kodu do pliku konfiguracyjnego mojego pakietu webpacka rozwiązało problem. Nie zapomnij zignorować folderu node_modules, ponieważ mogłoby to zabić wydajność dla HMR (Hot Module Replace):

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

Miałem ten problem podczas pracy z WebStormem.

Wyłączenie ustawień -> Ustawienia systemu -> „bezpieczny zapis” rozwiązało problem za mnie.

Zalecenia można znaleźć w: Rozwiązywanie problemów z pakietem WebPack

Aby dodać do możliwych rozwiązań: miałem folder projektu w folderze Dropbox, więc przeniesienie go rozwiązało problem za mnie. (OS X)

Moim problemem było rozróżnianie wielkości liter w folderach. Moje wywołania kodu do require () miały wszystkie nazwy ścieżek pisane małymi literami, ALE w rzeczywistości katalogi miały w sobie wielką literę. Zmieniłem nazwy wszystkich moich katalogów na małe litery, a oglądanie w sieci Web działało natychmiast.

Jednym z problemów jest to, że jeśli twoje nazwy ścieżek nie są absolutne, takie rzeczy się zdarzają. Ja przypadkowo ustawić resolve.rootaby ./zamiast __dirnamei to spowodowało mi tracić czasu kasowania i ponownego tworzenia plików, takich jak faceci powyżej mnie.

Jeśli zmiana fs.inotify.max_user_watches zgodnie ze wskazówkami Césara nadal nie działa, spróbuj użyć odpytywania zamiast natywnych obserwatorów, tworząc skrypt, jak pokazano w dokumentacji lub uruchamiając pakiet internetowy z --watch --watch-pollopcjami.

Zwróć uwagę, że jeśli uruchomisz pakiet WebPack na maszynie wirtualnej (Vagrant / Virtualbox) i zmienisz pliki na platformie hosta, aktualizacje plików w folderze współdzielonym mogą nie wywołać powiadomienia w systemie Ubuntu. Spowoduje to, że zmiany nie zostaną odebrane przez pakiet internetowy.

widzieć: bilet do Virtualbox nr 10660

W moim przypadku edycja i zapisanie pliku na de guest (in vi) wyzwoliło webpack. Edycja go na hoście (w PhpStorm, Notatniku lub jakiejkolwiek innej aplikacji) NIE uruchamia webpacka, cokolwiek zrobiłem.

Rozwiązałem to za pomocą vagrant-fsnotify .

Pracuj dla mnie w Laravel Homestead

--watch --watch-poll

Aktualizacje: usunięcie całego katalogu i ponowne klonowanie gita z repozytorium rozwiązuje mój problem.

Jeśli używasz Vima, powinieneś spróbować ustawić backupcopy na yes zamiast domyślnego auto. W przeciwnym razie Vim czasami zmienia nazwę oryginalnego pliku i tworzy nowy, co będzie zepsuło z zegarkiem webpack:

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

Po prostu dodaj to do swoich ustawień Vima, jeśli tak jest:

set backupcopy = yes

Miałem ten sam problem z plikiem .vue. Po ponownym uruchomieniu serwera wszystko działało dobrze, ale przy następnym zapisie nie był już rekompilowany. Problem dotyczył ścieżki pliku importu, w której jedna litera była wielka. Bardzo trudno zrozumieć ten problem, ponieważ wszystko działa po ponownym uruchomieniu serwera. Sprawdź przypadek swoich ścieżek.

Nie było to dla mnie rekompilacji, ale wtedy zdałem sobie sprawę / przypomniałem sobie, że webpack obserwuje wykres zależności, a nie tylko folder (lub pliki). Z pewnością pliki, które zmieniałem, nie były jeszcze częścią tego wykresu.

Dla mnie problemem było tworzenie folderów i plików w VS Code. Aby to naprawić, ponownie sklonowałem moje repozytorium i tym razem utworzyłem nowe foldery i pliki za pomocą wiersza poleceń zamiast kodu. Myślę, że kod z jakiegoś powodu uszkadzał pliki. Widziałem, że aplikacja została właśnie zaktualizowana, więc może to nowy błąd.

Miałem podobny problem, ani webpack, ani rollup w trybie zegarka nie łapały wprowadzonych przeze mnie zmian. Dowiedziałem się, że to w zasadzie moja wina, ponieważ zmieniałem moduł (plik .tsx), który nie był jeszcze zaimportowany w aplikacji (na przykład App.ts, który jest punktem wejścia) i spodziewałem się, że narzędzia do kompilacji zgłaszają błędy. wykonane tam.

Sposób, w jaki rozwiązałem ten problem, polegał na znalezieniu błędu dotyczącego wielkich liter w ścieżce importu. Folder w systemie plików miał pierwszą małą literę, ścieżka importu była wielka. Wszystko skompilowane dobrze, więc był to tylko problem z zegarem z pakietem internetowym.

Wystąpił również ten problem w maszynie wirtualnej VirtualBox (5.2.18) Ubuntu (18.04) używającej Vagrant (2.1.15) z synchronizacją rsync. Nagle pierwsza kompilacja działa świetnie, ale Webpack nie bierze pod uwagę późniejszych zmian, nawet z fs.inotify.max_user_watches=524288setem. Dodawaniepoll: true konfiguracji Webpacka też nie pomogło.

Tylko vagrant-notify-forwarder zadziałało (vagrant-fsnotify nie zadziałało z jakiegoś powodu), ale potem odbudowa nastąpiła zbyt szybko po zapisaniu pliku na hoście i przypuszczam, że rsync nie miał wystarczająco dużo czasu, aby zakończyć swoje zadanie (może ze względu na ilość synchronizowanych katalogów w moim pliku Vagrantfile?).

Wreszcie aggregateTimeoutsprawiłem, że zegarek znów działał, zwiększając również konfigurację mojego Webpacka:

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

Jeśli to rozwiązanie działa dla Ciebie, spróbuj ponownie obniżyć tę wartość, w przeciwnym razie będziesz musiał poczekać 10 sekund, aż kompilacja uruchomi się ponownie za każdym razem, gdy klikniesz Zapisz. Wartość domyślna to 300 ms .

Jaka była przyczyna w moim przypadku:

Wygląda na to, że wartość: max_user_watches w /proc/sys/fs/inotify/max_user_watches ma wpływ na pakiet

Aby sprawdzić rzeczywistą wartość

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

16384 było w moim przypadku i nadal to nie wystarczało.

Próbowałem różnych rozwiązań, takich jak:

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

Ale wydaje się, że nawet gdybym zmienił wartość, po ponownym uruchomieniu komputera wróciłby do domyślnego 16384.

ROZWIĄZANIE jeśli masz system operacyjny Linux (mój przypadek, mam Manjaro):

Utwórz plik:

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

I wypełnij go:

fs.inotify.max_user_watches=200000

Wydaje mi się, że 200000 mi wystarczy.

Po utworzeniu pliku i dodaniu wartości po prostu uruchom ponownie komputer i wszystko powinno być w porządku.

Mam ten sam problem. Zauważyłem, że nie kompiluje się, ponieważ mój folder zawiera jakiś znak (*). Wydaje się, że użycie starej wtyczki obserwatora rozwiązuje problem. Dodaj tę linię do pliku konfiguracyjnego pakietu internetowego.

plugins: [
    new webpack.OldWatchingPlugin()
  ]

Dla mnie usunięcie node_modulesi wykonanie instalacji npm lub przędzy ponownie, aby zainstalować wszystkie pakiety, rozwiązało problem

Prostym rozwiązaniem na MacOS jest:

Otwórz dwa okna terminala w tym samym katalogu, w którym znajduje się Twój projekt.

W pierwszym oknie terminala uruchom: webpack --watch

W drugim terminalu windows uruchom: webpack-dev-server

Wypróbowałem wiele możliwych rozwiązań i wydaje się, że jest to najbardziej niezawodne

Możliwe rozwiązanie: zmiana kontekstu na katalog aplikacji.

Wszystkie pliki konfiguracyjne Webpack miałem w podfolderze:

components/
webpack/
 development.js
app.js

W webpack/development.js, zestaw context: path.join(__dirname, '../')rozwiązał mój problem.

Po wypróbowaniu kilku strategii rozwiązania tego problemu po prostu się poddałem, ale podczas rozwiązywania innego problemu spróbowałem ponownie i nagle --watchflaga wreszcie działała.

Szczerze mówiąc nie wiem, co konkretnie sprawiło, że to zadziałało, ale po wykonaniu następujących kroków po prostu zaczęło działać:

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++

Mogło się zdarzyć, że podczas instalacji tych pakietów jakaś zależność właśnie dodała brakujący element układanki, kto wie ...

Mam nadzieję, że pomoże to każdemu, kto ma problemy z działaniem.

Dodam kolejną odpowiedź, ponieważ uważam, że jest to jak dotąd najlepsze rozwiązanie. Używam go codziennie i działa! Po prostu zainstaluj tę bibliotekę:

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

Opis: wymusza na programie webpack-dev-server zapisywanie plików pakietu w systemie plików.

Jak zainstalować :

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

Spróbuj zmienić --watchna-d --watch

pracował dla mnie

Jeśli zdarzyło się to nagle w Twoim projekcie, może to rozwiązać problem.

Może w jakiś sposób pliki, które śledziły zmiany w Twoim projekcie, których szukał webpack, zostały uszkodzone. Możesz je utworzyć ponownie, wykonując proste czynności.

1. come out of your project reż. ($: cd ..)
2. przenieś swój projekt do innego katalogu ($: mv {projectName} {newName})
3. przejdź do nowego katalogu ($: cd {newName})
4. uruchom serwer i sprawdź, czy ładuje się ponownie przy każdej zmianie pliku (powinien działać w większości przypadków, ponieważ teraz webpack tworzy nowe pliki do obserwowania zmian)
5. wyjdź z katalogu ($: cd ..)
6. przenieś go z powrotem do jego pierwotnej nazwy ($: mv {newName} {projectNam}) To zadziałało dla mnie ............

Natknąłem się na to pytanie, gdy miałem podobny problem - okazało się, że webpack nie jest ponownie pakowany, nawet podczas uruchamiania webpacka --config.

Usunąłem nawet plik bundle.js, a strona nadal wyświetlała się tak, jak przed moimi edycjami.

Dla tych z Was, którzy mają ten sam problem, w końcu zrobiłem opcję `` opróżnij pamięć podręczną i twarde przeładowanie '' w Chrome (kliknij prawym przyciskiem myszy przycisk ponownego ładowania przy otwartych narzędziach dev) i to wystarczyło

Spotkałem ten sam problem, próbowałem wielu rzeczy, w końcu Chrome Clear Browsing Data na Macu zadziałało.

Te moduły zostały zainstalowane:

"synchronizacja przeglądarki": "^ 2.26.7",

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

"webpack": "^ 4.41.2",

"webpack-cli": "^ 3.3.9"

Wystąpił problem z rozróżnieniem między plikami .js i .ts. Czemu ?

Podczas kompilacji projektu program Visual Studio kompiluje pliki maszynopisu do plików .js i .js.map. Jest to całkowicie zbędne, ponieważ pakiet webpack obsługuje również pliki maszynopisu (z awesome-typescript-loader). Podczas edycji plików .tsx komponentów w programie Visual Studio Code lub z wyłączoną funkcją compileOnSave opcją w tsconfig.json, edytowany plik ts nie jest ponownie kompilowany, a mój pakiet sieciowy przetwarzał nieaktualny plik .js.

Rozwiązaniem było wyłączenie kompilowania plików maszynopisu w Visual Studio podczas kompilacji projektu. Dodaj

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

w PropertyGroup twojego .csproj.