webpack --watch ne compile pas les fichiers modifiés

J'ai essayé de courir webpack --watchet après avoir modifié mes fichiers JS, cela ne déclenche pas de recompilation automatique.

J'ai essayé de réinstaller en webpackutilisant npm uninstallmais cela ne fonctionne toujours pas.

Des idées?

FYI: il semble qu'OS X puisse avoir un dossier corrompu et ne plus envoyer fsevents(que watchpack/ chokidar/ Finder utilise) pour lui-même et les dossiers enfants. Je ne peux pas être sûr que c'est ce qui vous est arrivé, mais c'était très frustrant pour moi et un collègue.

Nous avons pu renommer le dossier parent corrompu, puis regarder les événements se dérouler immédiatement comme prévu. Voir cet article de blog pour plus d'informations: http://feedback.livereload.com/knowledgebase/articles/86239-os-x-fsevents-bug-may-prevent-monitoring-of-certai

Les correctifs recommandés à partir du lien ci-dessus sont:

• redémarrage de l'ordinateur
• vérification du disque et réparation des autorisations via l'Utilitaire de disque
• ajouter le dossier à la liste de confidentialité Spotlight (la liste des dossiers à ne pas indexer), puis en supprimer, forçant efficacement une réindexation
• renommer le dossier, puis le renommer éventuellement
• recréer le dossier et y replacer l'ancien contenu

Les deux premiers n'ont pas fonctionné pour nous, n'ont pas essayé la suggestion Spotlight et la recréation ne s'est pas avérée nécessaire.

Nous avons pu trouver le dossier du problème racine en ouvrant Finder et en créant des fichiers dans chaque dossier parent successif jusqu'à ce que l'un d'eux apparaisse immédiatement (puisque Finder sera également arrosé par ce bogue). Le dossier le plus racine qui ne se met pas à jour est le coupable. Nous l'avons juste mvfait et l' avons mvremis à son nom d'origine, puis l'observateur a fonctionné.

Aucune idée de ce qui cause la corruption, mais je suis juste content d'avoir une solution.

Si votre code n'est pas recompilé, essayez d'augmenter le nombre d'observateurs (dans Ubuntu):

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

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

L'ajout du code suivant à mon fichier de configuration Webpack a résolu le problème pour moi, j'espère que cela vous aidera. N'oubliez pas d'ignorer votre dossier node_modules, car cela tuerait les performances de HMR (Hot Module Replacement):

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

J'ai eu ce problème en travaillant avec WebStorm.

La désactivation des paramètres -> Paramètres système -> "écriture sécurisée" l'a résolu pour moi.

Vous avez trouvé la recommandation de le faire dans: Dépannage WebPack

Juste pour ajouter aux solutions possibles: j'avais mon dossier de projet dans un dossier Dropbox, le déplacer a résolu le problème pour moi. (OS X)

La sensibilité à la casse des dossiers était mon problème. Mes appels de code à require () avaient tous les noms de chemin en minuscules MAIS les répertoires en fait contenaient une lettre majuscule. J'ai renommé tous mes répertoires en minuscules et l'observation des packs Web a fonctionné instantanément.

Un problème est que si vos noms de chemin ne sont pas absolus, des choses comme celle-ci se produiront. J'avais accidentellement réglé sur resolve.rootau ./lieu de __dirnameet cela m'a fait perdre beaucoup de temps à supprimer et recréer des fichiers comme les gars au-dessus de moi.

Si la modification de fs.inotify.max_user_watches comme indiqué par César ne fonctionne toujours pas, essayez d'utiliser l'interrogation au lieu des observateurs natifs en créant votre script comme indiqué dans la documentation ou en exécutant le webpack avec des --watch --watch-polloptions.

Notez que si vous exécutez webpack dans une machine virtuelle (Vagrant / Virtualbox) et que vous modifiez vos fichiers sur la plate-forme hôte, les mises à jour de fichiers dans le dossier partagé peuvent ne pas déclencher inotify sur Ubuntu. Cela empêchera les modifications d'être prises en compte par webpack.

voir: Virtualbox ticket # 10660

Dans mon cas, l'édition et l'enregistrement du fichier sur l'invité (dans vi) ont déclenché le webpack. Le modifier sur l'hôte (dans PhpStorm, Notepad ou toute autre application) ne déclenchera PAS le webpack quoi que je fasse.

Je l'ai résolu en utilisant vagrant-fsnotify .

Travaillez pour moi à Laravel Homestead

--watch --watch-poll

Mises à jour: la suppression de tout le répertoire et le clonage git à nouveau du dépôt résout mon problème.

Si vous utilisez Vim, vous devriez essayer de définir backupcopy sur yes plutôt que sur auto par défaut. Sinon, Vim renomme parfois le fichier d'origine et en crée un nouveau, ce qui va gâcher la montre Webpack:

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

Ajoutez simplement ceci à vos paramètres vim si tel est le cas:

set backupcopy = oui

J'avais le même problème sur un fichier .vue. Lorsque le serveur a redémarré, tout fonctionnait correctement, mais lors de la sauvegarde suivante, il ne s'est plus recompilé. Le problème concernait le chemin du fichier d'importation dont une lettre était en majuscule. Il est très difficile de comprendre ce problème car tout fonctionne lors d'un redémarrage du serveur. Vérifiez le cas de vos chemins.

Ce n'était pas une recompilation pour moi, mais j'ai ensuite réalisé / me suis souvenu que Webpack surveille le graphique de dépendance et pas seulement un dossier (ou des fichiers). Bien sûr, les fichiers que je modifiais ne faisaient pas encore partie de ce graphique.

Pour moi, la création de dossiers et de fichiers dans VS Code était le problème. Pour réparer, j'ai recloné mon dépôt et cette fois, j'ai créé de nouveaux dossiers et fichiers via la ligne de commande au lieu de Code. Je pense que Code corrompait les fichiers pour une raison quelconque. J'ai vu l'application juste mise à jour alors peut-être que c'est un nouveau bogue.

J'ai eu un problème similaire, ni le webpack ni le rollup en mode montre n'attrapent les modifications que j'ai apportées. J'ai découvert que c'était essentiellement ma faute car je changeais de module (fichier .tsx) qui n'était encore importé nulle part dans l'application (par exemple App.ts qui est le point d'entrée) et je m'attendais à ce que les outils de construction rapportent les erreurs. fait là-bas.

La façon dont j'ai résolu le problème a été de trouver une erreur de capitalisation dans un chemin d'importation. Le dossier sur le système de fichiers avait la première lettre minuscule, le chemin d'importation était en majuscules. Tout s'est bien compilé, il ne s'agissait donc que d'un problème d'inclusion de montre Web.

Il y avait également ce problème dans une VM Ubuntu (18.04) VirtualBox (5.2.18) utilisant Vagrant (2.1.15) avec synchronisation rsync. Du coup, la première compilation fonctionne bien mais Webpack ne prend pas en compte les changements par la suite, même avec fs.inotify.max_user_watches=524288set. L'ajout poll: truede la configuration Webpack n'a pas non plus aidé.

Seulement vagrant-notify-forwarderfonctionné (vagrant-fsnotify n'a pas fait, pour une raison quelconque), mais la reconstruction s'est produite trop rapidement après avoir enregistré le fichier sur l'hôte et je suppose que rsync n'a pas eu assez de temps pour terminer sa tâche (peut-être en raison du montant des répertoires synchronisés dans mon Vagrantfile?).

Enfin, j'ai fait à nouveau fonctionner la montre en augmentant également la aggregateTimeoutconfiguration de ma configuration Webpack:

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

Si cette solution fonctionne pour vous, essayez de réduire à nouveau cette valeur, sinon vous devrez attendre 10 secondes jusqu'à ce que la compilation redémarre à chaque fois que vous appuyez sur Enregistrer. La valeur par défaut est de 300 ms .

J'ai le même problème. Et je remarque qu'il ne compile pas car mon dossier contient un caractère (*). Et l'utilisation de l'ancien plugin Watcher semble résoudre le problème. Ajoutez cette ligne à votre fichier de configuration webpack.

plugins: [
    new webpack.OldWatchingPlugin()
  ]

Pour moi, la suppression node_moduleset la refonte de npm install ou yarn pour installer tous les packages ont résolu le problème

Quelle était la cause dans mon cas:

Il semble que la valeur de: max_user_watches dans le /proc/sys/fs/inotify/max_user_watches Webpack affecte

Pour vérifier votre valeur réelle

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

16384 était dans mon cas et ce n'était toujours pas suffisant.

J'ai essayé différents types de solutions comme:

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

Mais il semble que même si j'ai changé la valeur, lorsque j'ai redémarré mon PC, il reviendrait à la valeur par défaut 16384.

SOLUTION si vous avez Linux OS (mon cas, j'ai Manjaro):

Créez le fichier:

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

Et remplissez-le avec:

fs.inotify.max_user_watches=200000

Il me semble que 200 000 me suffisent.

Après avoir créé le fichier et ajouté la valeur, redémarrez simplement le PC et tout devrait aller.

Une solution simple sur MacOS est la suivante:

Ouvrez deux fenêtres de terminal dans le même répertoire que votre projet réside.

Dans la première fenêtre de terminal, exécutez: webpack --watch

Dans le deuxième terminal, les fenêtres exécutent: webpack-dev-server

J'ai essayé de nombreuses solutions possibles et cela semble être la plus fiable

Solution possible: changement de contexte dans le répertoire de l'application.

J'avais tous mes fichiers de configuration webpack dans un sous-dossier:

components/
webpack/
 development.js
app.js

Dans webpack/development.js, set a context: path.join(__dirname, '../')résolu mon problème.

Après avoir essayé une poignée de stratégies pour résoudre ce problème, j'ai fini par abandonner, mais en résolvant un autre problème, j'ai réessayé et tout d'un coup, le --watchdrapeau fonctionnait enfin.

Pour être honnête, je ne sais pas ce qui l'a spécifiquement fait fonctionner, mais après avoir effectué les étapes suivantes, il a commencé à fonctionner:

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

Il est peut-être arrivé que lors de l'installation de ces packages, certaines dépendances aient simplement ajouté la pièce manquante du puzzle, qui sait ...

J'espère que cela aidera quiconque a du mal à le faire fonctionner.

J'ajoute une autre réponse car je pense que c'est la meilleure solution à ce jour. Je l'utilise tous les jours et ça déchire! Installez simplement cette bibliothèque:

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

Description: force le programme webpack-dev-server à écrire des fichiers bundle dans le système de fichiers.

Comment installer :

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

Essayez de changer --watchen-d --watch

travaillé pour moi

Si cela se produit soudainement dans votre projet, cela peut résoudre le problème.

Peut-être que d'une manière ou d'une autre, les fichiers qui suivaient les modifications de votre projet recherché par Webpack ont ​​été corrompus. Vous pouvez les recréer simplement en suivant des étapes simples.

1. sortez de votre répertoire de projet. ($: cd ..)
2. déplacez votre projet vers un autre répertoire ($: mv {projectName} {newName})
3. aller dans le nouveau répertoire ($: cd {newName})
4. démarrez le serveur et vérifiez s'il se recharge à chaque changement de fichier (cela devrait fonctionner dans la plupart des cas, car maintenant webpack crée de nouveaux fichiers pour surveiller les changements)
5. sortir du répertoire ($: cd ..)
6. ramenez-le à son nom d'origine ($: mv {newName} {projectNam}) Cela a fonctionné pour moi ............

Je suis tombé sur cette question alors que j'avais un problème similaire - il est apparu que webpack ne rebondissait pas, même lors de l'exécution de webpack --config.

J'ai même supprimé bundle.js et la page Web s'affichait toujours comme avant mes modifications.

Pour ceux d'entre vous qui rencontrent le même problème, j'ai finalement fait l'option `` cache vide et rechargement dur '' dans chrome (cliquez avec le bouton droit sur le bouton de rechargement avec les outils de développement ouverts) et cela a fait cette astuce

J'ai rencontré le même problème, essayé beaucoup de choses, enfin Chrome Clear Browsing Data sur Mac a fonctionné pour moi.

Ces modules ont été installés:

"browser-sync": "^ 2.26.7",

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

"webpack": "^ 4.41.2",

"webpack-cli": "^ 3.3.9"

Le problème était de distiction entre les fichiers .js et .ts. Pourquoi ?

Lors de la génération du projet, Visual Studio compile les fichiers dactylographiés en .js et .js.map. Ceci est totalement inutile, car webpack gère également les fichiers dactylographiés (avec awesome-typescript-loader). Lors de la modification de fichiers .tsx de composants dans Visual Studio Code ou avec l' option compileOnSave désactivée dans tsconfig.json, le fichier ts modifié n'est pas recompilé et mon pack Web traitait un fichier .js non réel.

La solution était de désactiver la compilation des fichiers dactylographiés dans Visual Studio lors de la construction du projet. Ajouter

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

dans PropertyGroup de votre .csproj.